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ABSTRACT 


The development of an intelligent autonomous vehicle that can perform high risk 
missions or operate in environments too hazardous for humans has been a long 
Standing quest of the military community. The Autonomous Platform Simulator 
(APS) uses the flexibility and power of realistic graphical simulation to provide a low 
cost testbed for the study of real-time path planning algonthms and control strategies 
without the commitment of resources involved in building a prototype system. It is a 
bridge between the theoretical study of an abstract AI path planning problem and 
applied research, producing concrete performance measurements under realistic 
conditions. 

APS consists of one or more vehicle simulators, each implemented on a Silicon 
Graphics IRIS/4D-70GT graphics workstation. One vehicle simulator is linked with 
an AI agent path planner, implemented on a pair of Symbolics AI workstations using 
the Automated Reasoning Tool development shell. 

System trials demonstrated that APS was able to achieve real-time path planning 
and guidance of a realistically depicted ground vehicle navigating using digitized data 
of actual terrain. Communication bottlenecks currently limit the ability to make direct 
comparisons between human and machine control but the system holds promise to fill 


the gap as a pre-prototype autonomous platform simulator. 
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I. INTRODUCTION 


A. PROBLEM STATEMENT 

The development of a truly autonomous vehicle is a long sought after goal 
[DODSCI83, WEISN&89]. The more autonomy and intelligence such a vehicle has, 
the more it can replace humans for the performance of hazardous, strenuous, or repeti- 
tive tasks. Research in autonomous vehicles has largely focused on the development 
of control systems that totally replace human direction and move human interaction to 
higher levels of generalization and abstraction. Yet no broad comparison has been 
done of the performance of a human operator with varying levels of automated sup- 
port, versus purely autonomous control. The objective of this research is to create an 
Autonomous Platform Simulator (APS) in order to provide a facility for such compani- 
sons. Performance measurements, taken under varying combinations of human and 
AI agent control over a simulated vehicle navigating a tactical cross-country route, 
provide the yardstick to compare the studied modes of operation. 

One of the major tasks that an autonomous vehicle must perform is to plan a 
path to reach its goal and then navigate along that path. There are many algorithms 
for calculating (planning) an optimal path based on some traversal cost criteria 
[RICHBG87 contains an excellent survey of path planning methods]. In the 
construction of an autonomous vehicle prototype, one methodology is usually chosen 
and then frozen by the investment in the implementation. Another aim of the APS 
system is to provide a means for comparing the performance of path planning 
algorithms in a practical setting using real world terrain data. The replacement of an 
actual vehicle with a realistic graphical simulation is desirable for this research 
because different algorithms, hybrid control configurations, and other features can be 
Studied without the cost of building a physical system, the risk of damage to an actual 


vehicle, or the risk of injury to a human driver. For this research effort, the physical 


vehicle and its onboard navigation and control systems are simulated on a Silicon 
Graphics IRIS/4D-70GT graphics workstation. 

In the APS system the simulated vehicle navigates along a pre-determined path 
toward a known goal. The path is produced by either an AI agent or a human planner 
from global terrain data, such as a map, which does not contain the location of obsta- 
cles, such as minefields, which may force a deviation from the original path. Various 
performance measures are monitored to evaluate different combinations of autonomous 
and human control. The AI agent planner is implemented on a dedicated AI worksta- 
tion, a Symbolics 3650. The expert system shell used in this study is ART, produced 
by Inference Corporation [INFRNC85]. 

In developing an autonomous vehicle simulation with selectable modes of vehi- 
cle control and path planning, four distinct modes of operation are implemented charac- 
terized by whether a human operator or Al agent is performing the function. The four 
combinations studied are: 

1 - Human path planning and a human driver. 

2 - Human path planning with an autopilot capable of following the calculated path. 

3 - Path planning by an expert system with a human driver controlling the vehicle 
based on received path points. 

4- Total autonomous (hands-off) control. 

The hierarchy involved in these tasks recognizes another level above the two so 
far discussed, that of mission planning, which designates the vehicle’s final objective or 
goal point of the path. In APS, the output of the mission planning process is considered 


a given and is always entered by the human commander. 


B. THESIS ORGANIZATION 
The work done in this thesis breaks down into two major areas: vehicle simula- 


tion and path planning. Work done in the vehicle simulation arena was performed by 


Teter. Work done in the path planning arena was performed by Shannon. The commu- 
nications work was completed by both authors. 

Chapter II contains an overview of previous work done in path planning, communi- 
cations, and real-time vehicle simulation that relate to this study. Chapter III con- 
tains a detailed discussion of the development of the algonthms and _ simulator 
software developed during this study. This chapter also covers the simulator vehicle 
environment, the characteristics that allow the simulated vehicle to react realistically, 
and detailed discussions of path planning algorithms. Chapter IV contains discus- 
sions on the final system implementation. Chapter V examines the final APS system. 
Finally, Chapter VI contains the authors’ views regarding the limitations of this study 


and possible areas for future research. 


Il. BACKGROUND 


This chapter provides a survey of previous work in graphical vehicle simulators 
and path planning with special emphasis on research done at the Naval Postgraduate 


School that laid the foundation for the APS project. 


A. VEHICLE SIMULATORS 

The vehicle simulator component of the APS system evolved out of an effort to 
enhance the Moving Platform Simulator (MPS) [FICHTN&88], a real-time visual 
simulation of the Fiber Optically Guided Missile (FOGM), ground vehicles, and three 
dimensional terrain, which was itself the result of a continuing series of real-time 
visual simulations of ground, sea, and air platforms constructed by students at the 
Naval Postgraduate School [OLIVER&87, SMITHD&87, MCNKLE&88, 
WINN&89]. 

APS was first implemented using the Firing Platform Simulator, FPS, a close 
cousin of MPS. FPS was a class project which added multiple independent views and 
ground vehicles that could engage each other with weapons systems. Since MPS is 
the direct ancestor of both APS and FPS, its description provides an understanding of 


the context upon which the vehicle simulator was built. 


1. The Moving Platform Simulator 

The Moving Platform Simulator [FICHTN&88] was developed at the Na- 
val Postgraduate School on a Silicon Graphics, Inc. IRIS 4D/70-GT graphics worksta- 
tion. MPS allows a user to select a view from either a ground vehicle or FOGM 
missile and guide the platform over a three-dimensional view of a 10x10 kilometer ar- 
ea of Fort Hunter-Liggett, California. The FOGM missile is able to target, track, and 
destroy vehicles on the ground. The elevation data for the simulation was provided by 
the U. S. Army’s Combat Developments Experimentation Center (CDEC) at Fort 


Ord, California. MPS accepts standard digital map data for other areas of the world. 


Ground vehicles in MPS are controlled by dials on a penpheral input de- 
vice. Control response is immediate. Changes in vehicle course and speed, for exam- 
ple, are effective during the next display cycle, making them essentially 
instantaneous. The major portions of MPS adopted unchanged for APS are the dis- 
play routines, terrain representation, window manager interface, FOGM modeling, 


and the overall program structure. 


2. The Firing Platform Simulator 
The Finng Platform Simulator was a class project that enhanced the 
ground platform capabilities in MPS by adding a more realistic image of a tank 
(Figure 2-1), multiple independent viewing axes, and engagement between ground 
vehicle weapon systems. A set of driver’s controls were added using a mouse to let 


the user manipulate the throttle, brakes, and steering. 


3. Vehicle Motion Modeling 

Realistically simulating the response of vehicles to controls, such as 
throttle and steering, and to changes in the terrain, is often neglected in a graphical 
Simulation because a complete model of the physics of motion would be both 
analytically complex and computationally expensive. Complete modeling of the 
mechanics of vehicle motion is a complex proposal [BARNAC64]. Much of the 
modeling effort of engineers has therefore focused on analyzing a smaller subproblem 
such as the characteristics of a vehicle subsystem like the steering or suspension. 
Past work at NPS, such as that of Tan [TAN86], has studied various control 
algorithms for an autonomous vehicle following a curving road at constant velocity. In 
Tan’s study vehicle mechanics were modeled by numerically integrating second order 
equations of motion for an idealized point mass. Numerical integration provides for 
accurate answers to vehicle motion equations, but at the cost of extensive 
computation. The modeling requirements of APS are both more general and more 


constrained: more general in realistically modeling the effects of control inputs and the 
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effects of vehicle interaction with varying terrain - more constrained by not being able 
to afford an increase in the computational burden from modeling because of the effect 
on overall performance. 

Real-time graphical moving platform simulations often consume most of 
the computing resources of a graphics system in realistically depicting terrain and ve- 
hicles [FICHTN&88: pg 72]. Many graphics researchers shy away from more realis- 
tically modeling of the effects of steering and terrain in the belief that the problem is 
too hard and the necessary code would be too slow. What is sought for APS 1s a sim- 
plified model of vehicle motion and control response designed for a class of ground 
platforms moving off-road across varying terrain. An interesting candidate vehicle 
model was developed by Ross at NPS [ROSS89]. Ross’s work provided a thorough 
but computationally simple model of vehicle-terrain interaction and energy costs 
while traversing varied terrain regions. Unfortunately, his model’s assumption of con- 
Stant velocity and its requirement for homogeneous terrain patches make it unsuitable 
as a basis for the APS vehicle simulator. However, his work has great potential as 


an alternate cost function for path planning. 


B. AUTONOMOUS VEHICLES 

Research in autonomous vehicles received great impetus in recent years from 
DoD’s Strategic Computing Initiative [DODSCI83] which called for a push of 
"machine intelligence technology" in applied research. One of its three demonstration 
projects is the Autonomous Land Vehicle program. Much of the work generated on 
autonomous vehicles has focused on vision systems, local obstacle avoidance, such 
as FMC Corporation’s Autonomous Vehicle [NITAO&88], and road following 
guidance, such as Martin Marietta’s ALV [LOWRIE85]. Since APS doesn’t have 
local obstacles to avoid or roads to follow, such research, while stimulating, lacks 
direct applicability. The autonomous vehicle prototypes do, however, provide insight 


into the functional decomposition of the problem of autonomous vehicle navigation and 


control. For example, both autonomous vehicles mentioned above separate path 
planning from vehicle navigation and control, to the extent of having different 
hardware perform those functions. 

The most productive source of techniques for modeling vehicle motion and 
response turned out to be basic physics texts such as Marion’s Classical Dynamics 
[MARION70] or the late Richard Feynman’s Physics Lecture Series [FEYNMN63]. 
Robotics applications [FRANK69] also provide some usable techniques. Starting 
then, from the solid ground of physics, albeit with several simplifying assumptions, 
the iterative nature of the graphics drawing loop can be used to break vehicle motion 
into small enough increments so that all equations of motion can be modeled with 
functions of no higher than first order terms and without numeric integration. More on 


this topic is presented in Chapter III. 


C. PATH PLANNING 

The task of planning a path across a known region has been classified as a 
weighted-region problem [RICHBG87: pg 15]. The weighted-region problem requires 
finding the optimal-cost path between two known points given an appropriate area- 
cost map. The area-cost map is described as a two dimensional region that is divided 
into sub-regions containing a value of traversal for each sub-region. Solving the 
weighted-region problem requires searching this two dimensional region. There are 
many strategies that can be applied to this problem of path planning. Each strategy 
has unique characteristics that determine its suitability. Two areas that have a major 


impact on path planning are terrain representation and search methods. 


1. Terrain Representation 
Natural terrain is generally not discrete nor clearly defined by regular 
boundaries. A variety of terrain models are used to depict natural terrain. The choice 


of terrain representation affects the choice of the search method used, and conversely 


the choice of a particular search method limits the terrain representations that can be 
used. 
a. Cartesian Grids 
Regular geometric grids are used to divide the terrain into small regu- 
lar cells that are used to classify some aspect of the terrain. In work done by Felhoe- 
lter, [FELHOE88: pg 36-37] slope data derived from a DMA source file of Fort 
Hunter-Liggett is used to classify each cell of the region. A wavefront search method 
can then applied to this type of region representation to find the optimal path between 
two points [ROWE&88: pg 2]. 
b. Hierarchical Models 
A hierarchical terrain representation, as used by Metea and Tsai 
[METEA&87], is a variation of the Cartesian method used above, and is used to di- 
vide terrain into increasingly fine geometric grid cells. The lowest level contains the 
highest resolution data. Each cell within a level contains a single number that 1s asso- 
ciated with the cost of traversal. At the lowest level, this number is normally a direct 
representation of some aspect of the patch of terrain represented. At each succeeding 
level, the values of the cells of the preceding level that are contained in a cell of the 
next level are used to calculate the value of that cell. 
Alternative forms of hierarchical terrain representation [KUAN84, 
ROSS89] move away from the Cartesian grid representation. These models group re- 
gions from a lower level that have similar representational value into larger regions at 
succeeding levels. The salient point of this approach is that hierarchical terrain mod- 
els group terrain information from a lower level into larger regions at higher levels. 
c. Homogeneous Model 
Homogeneous terrain representation [ROSS89] groups contiguous 
points, with identical costs of traversal, within an arbitrary convex polygon. The ho- 
mogeneous terrain model allows large areas of terrain to be grouped and stored effi- 


ciently in the terrain data base. It also removes the directional biases imposed on the 


terrain by Cartesian terrain models. This representation is required for certain types 
of path planning techniques. One such technique involving Snell’s law uses the princi- 


ples of optics to find paths across homogeneous regions[ROWE87, ROWE&88]. 


2. SEARCH METHODS 
The backbone of any path planner is the search algorithm used. The choice 
of which search algorithm to use is based on many factors. One key factor already dis- 
cussed above is the terrain representation used. The following search methods are 
discussed briefly with emphasis on the impact of the choice of terrain model. 
a. Wavefront 
Wavefront planning needs a terrain model that divides the search ar- 
ea into uniformly sized cells, typically Cartesian grid cells, where each cell contains 
its cost of traversal. This technique uses a modified breadth first search where ex- 
pansion is accomplished according to the cost of traversing a cell instead of simply ex- 
panding from one level of cells to another [RICHBG87]. Disadvantages to this 
approach are as follows: 
(1) The terrain is cut up into uniform pieces no matter what the 
lay of the land is. This is of concern because the resolution of the search region is a di- 
rect reflection of the resolution of the cells that make up the search region. 
(2) The wavefront algorithm investigated in this thesis expands 
to the 8 neighbors of a square grid cell, causing motion to be restricted to straight 
lines, in the vertical, horizontal, and diagonal directions, between a cells. 
(3) Finally there is a certain amount of waste associated with 
the propagation of a wave. The entire wave must be expanded instead of just follow- 
ing the most likely path. This same problem of an ever expanding agenda is associat- 
ed with a pure breadth first search. 
The major advantages of this algorithm are that it is guaranteed to 


find the optimal path and it is well understood. 
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b. Depth-First 

A depth-first search is used by Goodpasture [GOQODPA87]} to pro- 
vide motion planning for a computer simulation of an autonomous walking machine. 
The depth-first search algorithm is guaranteed to provide a path if one exists. It how- 
ever, does not guarantee finding an optimal path. The first path found is the path cho- 
sen. The algorithm used simply explores neighboring nodes that have not been 
explored or are not obstacles. A node is chosen that is closest to the goal. This strat- 
egy is followed untl the goal is reached or the trail ends. If the trail ends, the algo- 
rithm backtracks the path, marking the used nodes as obstacles, until it finds an 
unexplored node to follow. If an unexplored node is found the search is continued as 
before. If the start point is returned to, and no unexplored nodes are available, the 
search fails. That is, no path is possible. The depth-first search is best used where 
" "no-go" terrain features are used. 


c. A Star (A*) 


"gO 


The A* search combined with Snell’s law is used to solve long range 
path planning problems, where the terrain 1s divided into homogeneous-cost regions. 
Variations of Snell’s law are used to find possible paths to the goal, across the homo- 
geneous-cost regions. Then the A* search is performed using evaluation values de- 


veloped from the A* search [RICHBG87]. 


D. EXPERT SYSTEM SHELLS 

Technology has advanced beyond the days of using a general purpose computer 
merely to relieve humans of the tedious tasks of redundant mathematical calculations 
or the endless searching of records. It is now possible to undertake more complex 
tasks with improved accuracy. Specifically, the growing complexity of model 
representation combined with a limited understanding of the processes of human 
thought and reasoning, have led to the use of logic oriented languages to help 


represent rules used in human decision making. Two such logic oriented languages 
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are LISP and Prolog. But these languages require the researcher to be very closely 
tied to the machine environment. With these languages, the programmer is directly 
involved in the detailed management of rules and facts. The desire to remove the 
burden of rule and fact management has lead in part to the development of expert 
system shells. 

The use of expert system shells as logical programming environments provides 
an arena for the development of computer programs to solve problems otherwise 
difficult to formulate. These environments or shells provide such features as backward 
chaining, forward chaining, inheritance, and fact and rule management. Backward and 
forward chaining control strategies provide one of the critical features of expert 
system shells, since these strategies constitute inference engines. The _ ideal 
inference engine allows rules to fire independently of the order with which the 
programmer places the rules in the program control structure. Actual inference 
engines contained in expert system shells may fall short of this ideal, but such shells 
provide a tool that allows programmers to think of rules as independent islands of 
action waiting for the ocean of knowledge around them to provide the preconditions for 
their firing. The expert systems shells available at the Naval Postgraduate School are 


KEE by Intellicorp [INTEL86], and ART by Inference Corporation [INFRNC85]. 


E. COMMUNICATIONS 

The real time control of a visual simulation can involve the use of more than one 
type of architecture. The ability to transmit and receive control information and 
working data between processes implemented with different architectures was 
investgated by Barrow [BARROW88]. The medium of communication between the 
various architectures was TCP/IP using the Ethernet. The principal forms of 
communication investigated were I/O stream and broadcast. 

Broadcast datagrams were used by Barrow to communicate between IRIS 


workstations. They provided a convenient way to send discrete messages without 
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connecting hosts or requiring a specific host address. This method of communication 
was not supported between UNIX TCP/IP systems and the Symbolics CHAOSNET, 
sO stream communications were used. The package of routines developed supported 
messages containing a single character or number with the UNIX side of the 


connection required to act as the connection server. 
F. DEVELOPMENT SYSTEM DESCRIPTION 


1. IRIS Graphics System 
a. SGIIRIS/4D-70GT Graphics Workstation Description 
The IRIS/4D GT is a line of high performance graphics workstations 

with extensive hardware support for graphics modeling that can support the real-time 
3D drawing of the large number of polygons necessary in a realistic vehicle simulator 
[ZYDA&8&8]. This system has the following performance characteristics: 

¢ 10 MIPS cpu (MIPS, Inc. R2000 RISC Processor). 

¢ 40,000 10 X 10 pixel quadrilaterals per second ( lighted & Gouraud shaded). 

¢ 24-bit Z-buffer. 


¢ Parallel modeling matrix operations. 


.¢ Hardware transformation matrix stack. 


b. Software 
The following software products were used in the development of the 
APS system: 


¢ SGI C (MIPS) compiler. 
¢ UNIX system V Operating System with TCP/IP Network extensions. 


¢ SGI 4Sight™ Window Manager. 4Sight manages screen and I/O resources of 
the IRIS workstation. It supports graphics clients using the SGI graphics li- 
brary as well as programs written for NeWS and XWindows[SGI4UG88]. 
APS runs as a client under the 4Sight server using the graphics library inter- 
face for maximum performance. This gives APS the flexibility of running in a 
window of arbitrary size and location. The window manager also provides the 
popup menu services used extensively by APS. 4Sight also provides a font 
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manager to scale and render text fonts in prompts, legend text and displayed 
messages. 


2. | Symbolics 
a. Symbolics 3600 
Symbolics 3600 workstations were chosen to perform the path plan- 
ning tasks of APS. The Symbolics family of symbolic processing machines are de- 
signed with a proprietary CPU, which allows these systems to have LISP and other 
symbolic programming languages implemented more efficiently and effectively than 
conventional computers. Much of the efficiency and effectiveness of the Symbolics 
workstations is obtained through hardware implementation of some system manage- 
ment schemes. Some of the special architecture features used in the Symbolics work- 
stations includes: tagged architecture, multiple caches, hardware stack pointers, 
pipelined instruction cycles, and parallel processing [SYMBOL88]. 
b. Software 
The following software products were used in the development of the 
path planner for the APS system: 


¢ Symbolics Operating System, Genera 7.1, provided a consistent background 
for the programming environments. 


¢ The Automated Reasoning Tool (ART) by Inference Corporation is the princi- 
ple control language for the AI Agent. This rule-based, symbolic programming 
language is implemented on Symbolics workstation SYM4. 


¢ Symbolics Common LISP is used to provide access to existing path planning 
search algorithms and communications code. 


3. Network 


Computer systems in the NPS Computer Science Department are linked 


through an Ethernet local area network connecting some 76 stations. Average day- 


time traffic 1s 25 packets/second or 30% peak utilization in worst 20 second period!, 


Based on a 24-hour test period during January 1989. 
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The portion of the network used by APS is shown in Figure 2-1. The vehicle simula- 


SYMBOLICS 


| SS multiport network interconnect 


ETHERNET (10 MB/sec) 





Figure 2-1 Network Physical Topology 


tors (commander and driver) are connected directly to the main Ethernet cable seg- 
ment. The Symbolics AI workstations are connected to the network through a 
mulitport network interconnect, a Digital Equipment DELNI. The flow of communica- 


tions as seen by APS is shown in Figure 2-2. 


ART Client 


Vehicle 
Al TCP/IP Stream Simulator 





| BROADCAST 
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PATH Vehicle 
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Figure 2-2 Network Logical Topology 
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I. METHODOLOGY AND ASSUMPTIONS 


In this chapter, different candidate methodologies and algorithms are explored 
and the rationale behind the ones chosen discussed. The goal is to explain why cer- 
tain design decisions were made and how previous work was utilized. Small seg- 


ments of code or ART rules are included to show the flow from theory to application. 


A. DEFINITIONS 

The following terms are defined here either because they are either used in a 
non-standard manner or are key to the concepts presented in this thesis. 

Slope Angle - The magnitude (absolute value) of the angle between the planar 
terrain polygon and the horizontal plane. 

Local Platform - A platform added at the driver’s vehicle simulator. 

Net Platform - A platform added at a remote vehicle simulator and updated 
over the network. If a network platform is selected to operate, only the viewing 
controls are active. Other vehicle parameters are controlled by its home simulator. 

NOGO Terrain - Terrain classified as having a trafficability of zero. 

Path - A list of two or more terrain points. The first point on the path is its 
Start, the last point is its goal. 

Terrain Polygon - Planar polygon having uniform slope. In APS these are 
triangles, one half of a terrain grid defined by the four elevations at the vertices. 

Trafficability - The relative speed at which a vehicle can traverse a class of 
terrain due to roughness, obstacle density, soil conditions, etc. In APS trafficability is 


purely a function of the magnitude of the slope angle. 
B. VEHICLE SIMULATOR 


The vehicle simulator portion of APS provides for a realistic depiction of a tacti- 


cal platform, its control response, and its interaction with the terrain in a graphical 
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simulation without the overhead of completely modeling the full suite of time consum- 


ing and complex physical motion and dynamics. 


1. Assumptions 
The vehicles and terrain simulated in this study are assumed to have the 
following characteristics: 


¢ Tracked or wheeled tactical vehicle travelling offroad, capable of traversing 
60% slope. 


| ¢ Trafficability of slope limits vehicle speed before stability limit is reached. 
¢ Trafficability of slope limits vehicle speed before engine power. 


¢ Single gear ratio modeled. (Although different gears could be modeled by us- 
ing an array of time constants). 


| 2. Coordinate Systems 

The SGI graphics software library uses a three-dimensional (3D) graphics 
world coordinate system (Figure 3-1) in which the Z axis represents depth, distance 
from a plane perpendicular to the eye, rather than altitude or elevation. Another coor- 
dinate system is used when planning a route across terrain, corresponding to a two- 
dimensional (2D) view of the terrain from directly above. This is the Universal Trans- 
verse Mercator Projection, (UTM) coordinate system and is used for path planning, 
as in a military map, and is the coordinate system used for the terrain database. In 
the UTM system each point is represented by a Grid Zone Designator, a distance in 
meters North from the Gnd Zone origin (a northing), and a distance in meters East 
from Grid Zone origin (an easting). The UTM coordinates of a point (x,y,z) defined in 
the graphics world coordinate system can be found by: 


utm_x= x+(x_grid* 10.0); 
utm_y = -z + ( y_grid * 10.0); 
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Figure 3-1 Graphics World Coordinate System 


3. Platform Rotation Angles 

In order to model moving objects, a convention must be established for the 
rotation of the body (platform) axes in relation to the graphics world axes. Normally 
a platform’s direction or heading is given as counterclockwise degrees from North. 
Weapon systems such as artillery pieces are also aimed or "laid" using an azimuth, 
an angle that follows the same convention for direction but a uses a different unit of 
angular measure, mils (milliradians). The SGI graphics system and APS follow a dif- 
ferent convention. Rotation angles are measured as counterclockwise angles from the 
positive axis. Thus a vehicle heading due North would have an azimuth (rotation 
about the world Y axis) of 1.57 radians or 90 degrees’. Other rotation angles follow 
normal right-hand rule conventions except in the case of roll. With body axes as- 
signed as in Figure 3-2, the following conventions are established for APS: 


' Graphics primitives use degrees but the C library functions use radians. All angles in APS are stored as radians and converted as 


necessary. 
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azimuth - Rotation about the Y-axis 1s in the mght-hand sense, from the 
positive X-axis, Counterclockwise as an observer looks along the 
positive Y-axis toward the origin. Also called platform’s course or 
orientation. 

pitch - Rotation about the Z-axis is in the nght-hand sense, from the 
positive the X-axis, Counterclockwise as an observer looks along the 
positive Z-axis toward the origin. Angle between ground (X-Z) plane 
and body X-axis. 

roll - Rotation about the X-axis 1s opposite to the right-hand sense from 
the positive Z-axis. Here the rotation is Clockwise as an observer 
looks along the positive X-axis toward the origin. 

heading - Compass course is a Clockwise angle in degrees between 
north (world minus Z-axis) and vehicle X-axis. Not used internally in 
the model, but it 1s used to display platform azimuth to the user. 


World Y 


World ° 





Figure 3-2 Body vs World Rotation Axes 


4. Coordinate System Transformations 
Since the user’s viewpoint is fixed with respect to the vehicle or body axis, 
and the graphics software requires such points in terms of its own world unrotated ax- 
is, there 1s a requirement to transform points between coordinate systems. The posi- 
tion of a coordinate in a rotating coordinate system with respect to a fixed or reference 


coordinate system can be represented by a 3 X 3 rotation matrix Mppy. The rotation 


Ik 





angles are known as "Euler" angles. The rotation matrix representing rotations about 
Euler angles, called yaw (wy), pitch (8), and roll (), in that order is: 
Mror = Rz, ron Ry, pitch Rx, yaw [FU&87: pg 25] = 


cosycos8 cosysinOsind - sinycosd cosysinOcosd + sinysingd 
sinycos@ sinysinOsind + cosycosd sinwysinOcosy - cos@sing (3-1) 
-sin8 cos@singd cosO8cosd 


The transformation of a three dimensional vector representing the body off- 


set to the fixed reference is achieved by pre-multiplying' Mpor by the vector or: 
Pw = Ps Mror (3-2) 


This transformation requires the following operations: 


3 Sin function calls 

3 cos function calls 

16+9 floating point multiplications 
4+6 floating point add/subtract 


Fortunately the overhead of these operations can be avoided by solving a 
more general problem that includes translation and scaling during the transformation. 
Such a transformation from body to world coordinates is normally done by means of a 
4X 4 homogenous transformation matrix. This matrix represents the location of a ro- 


tated and/or translated coordinate system (body), with respect to a fixed coordinate 


A A A 
system (world). Symbolically then, the transformation is Py = P, Mror where P 


represents the 4 X 1 homogenous coordinate vector. 
The geometry engine of the IRIS is designed to perform these type of 


transformations using 4 X 4 matrix operations efficiently. The world coordinates of 


‘Note that in graphics a body offset is transformed to where it would appear in world coordinates so the rotation matnx is pre-mul- 
uplied by the position vector. In robotics where objects actually move the rotation matnx Is post-multiplied by the position vector. 


20 


the eye position vector, for example, can be calculated by having the IRIS hardware 
perform rotations as if the body were an object about to be drawn and pre-multiplying 
the rotation sub-matrix of the result by the offset vector. The result is the world coor- 
dinate offset position. Figure 3-3 is an extract of transform_body_to_world that per- 


forms these operations using the IRIS hardware. 


/* Do rotations in reverse gimbal order */ 

rotate( (Angle)(azimuth*RTOD_X_10), ’Y’ ); /* azimuth */ 
rotate( (Angie)(elevation*RTOD_X_10),’Z’ ); /* pitch */ 
rotate( (Angle)(-roll*RTOD_X_10), 7); /* roll */ 


getmatrix( offset_mx ); /* Get accumulated rotation matrix */ 

*eye x = dx*offset_mx([0)[0] + dy*offset_mx([1)][0] + dz*offset_mx[2](0]; 
*eye y = dx*offset_mx(0)[1] + dy*offset_mx{1)[1] + dz*offset_mx[2)][1]; 
*eye z= dx*offset_mx[0][2] + dy*offset_mx[1][2] + dz*offset_mx[2][2]; 





Figure 3-3 Transforming Body Offsets to World Coordinates 


5. Physics of Motion 

Vehicle motion and control response is modeled as changes in the vehicles 
velocity vector v, with changes in its magnitude being acceleration or braking, and 
changes in its direction being steering. The model treats control inputs as changes to 
the normal constant velocity equilibrium state on level ground. The vehicle engine, at 
a particular throttle setting, provides sufficient force to overcome all resistance forces 
and maintain a certain speed corresponding to equilibrium between propelling and 
resistance forces. If the propelling force is increased then the vehicle will accelerate 
up to a new equilibrium velocity. If throttle is decreased then it will "coast" down to a 
new equilibrium velocity. The vehicle velocity corresponding to maximum throttle is a 


program constant, MAX _GNDSPEED = 45 MPH.'. Braking is modeled as 


1 . 

In APS there is one set of model constants. All types of vehicles react and "feel" the same to the driver. A jeep accelerates 
no faster than a tank. However, these constants could fairly easily be expanded to an array of constants indexed by vehicle 
type. 
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deceleration at a vanable but velocity independent rate. Steering response is 
modeled as an exponential function of time. 


a. Friction and Coasting 
A vehicle of mass m, and velocity vector wv travelling on a level sur- 


face, has momentum my? At equilibrium, the only forces opposing motion are frictional 
resistance forces, F'p. Frictional rolling resistance is largely fluid friction and comes 


from air resistance, lubricant fluid resistance in bearings and gears, tire deformation 


while rotating, soil deformation, etc. For each resistance force 
F, = -kmv" viv (3-3) 
Different resistance forces have different exponents for v. For exam- 
ple, for air resistance at low speeds (< 24 meters/sec), n = 1 [MARION70: pg 53]. 
In fact for all resistance forces at the range of speeds dealt with in this study, n < 1 1s 
assumed. For simplicity a convenient approximation is made that the force contribu- 
tion from all sources of resistance can be combined into one resistance force with n = 
1, with some combined constant k. 
Looking at just at the magnitude of the resistance force and remem- 
bering that it is always opposite the direction of motion, (3-3) becomes: 
Fp, = ma = mdv/dt = -kmv (3-4) 


Eliminating constant mass and integrating over time this becomes: 


J aviv =-kJ at (3-5) 
which has a solution of the form: 

Inv=-kt+C (3-6) 
Using the initial condition v(t=0) = v, means C = In v.. Taking the exponential of both 
sides gives: 


elnv =@ (-ks x Invo) (3-7) 


22 


vre -kt -¢ Invo (3-8) 


v=vie “kt (3-9) 


Lett = l/k. Thenv=vy,e “kt — v. lfe=v// 2.718. The quantity I1/k 1s called a time 
constant and corresponds to the time it takes the velocity to decrease to = one third of 


its original value. This time constant, T, can therefore be used to calculate an average 
rate of change per unit time or: 
v=v-(v: at/T) (3-10) 

Note that this equation depends only on the time interval and velocity at the begin- 
ning of the time interval. It also avoids calculating the exponential function. The con- 
stant T controls how quickly the vehicle coasts to a stop or lower equilibrium speed. 
A large value of t corresponds to a streamlined, wheeled vehicle on hard pavement, 
as opposed to a small value of tT which might represent a track laying vehicle in mud- 
dy soil. The coasting function (3-10) 1s coded as: coast_vel = currvel - ( currvel / 
COASTING_TIMECONSTANT * elapsedsec);. 

An analysis of a typical case shows how well this code fragment pro- 
duces the same result as equation (3-9). For COASTING_TIMECONSTANT = 10.0, 
elapsedsec = ().5, and currvel = 40 MPH, after 10 seconds elapsed time, (3-9) yields 
14.72 MPH while the code produces 14.34 MPH. In APS the final velocity for coasting 
need not be zero. It could be a lower equilibrium velocity. The exponential nature of 
the decrease in velocity means that the new velocity would be approached asymptoti- 
cally, never actually reaching the target velocity (variable cmdvel). Therefore there is 
a cutoff in the procedure velocity_model, to wit: 

If ( fabs( cmdvel - currvel ) < TO_MPS ) return( cmdvel); 


This returns the selected velocity as the current velocity 1f it is already within 1 MPH. 
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b. Braking 
Deceleration due to braking can be modeled as a variable resistance 
force that is independent of velocity. For a braking factor b,0.0<sb< 1.0, 
Furawp = 4 =m 0 dvidt = -kppaxR™ 9 (3-11) 
Eliminating constant mass and rearranging, the new velocity is given by: 
v=v +dv= v\+(-Kpeaup O dt) (3-12) 
or, in code: 
newvel = currvel + (MAX_DECELERATION * brake_factor * elapsedsec ); 
where MAX_DECELERATION is a constant representing the maximum rate of deceler- 
ation before skidding (shear force between vehicle and ground > frictional force) and 
brake_factor represents the input to the model from the vehicle controls, a value of 0.0 
representing no braking down to -1.0 or 100% braking. This control input can come 
from dials, the mouse or be calculated by an autopilot. 
c. Acceleration 
Acceleration corresponds to advancing the throttle position to a new 


velocity position, v,, Causing engine output to exceed the propelling force necessary to 


overcome the current rolling resistance. It assumes linear engine power output. Sub- 


tracting equilibrium forces at the current velocity, v,, gives: 


F, =m dv/dt=k,( Vr+ Vv.) m (3-13) 
dv=k,( Vr: Vv.) dt (3-14) 
dv=1/t( v,- v,) dt (3-15) 


Where T is again a time constant = 1 /k Ke Equation (3-15) is implemented as: 


newvel = currvel + ( ( cmdvel - currvel ) * dt / ACCELERATION_TIMECONSTANT; 
For ACCELERATION TIMECONSTANT = 10 seconds and cmdvel = 40 MPH, this 


gives: 


0 => 20 MPH in 6 seconds 
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0 = 30 MPH in 11 seconds 
0 => 40 MPH in 21 seconds 


This compares well with the nominal acceleration for the US M1 Tank of 0 => 20 
MPH in 7 seconds [JANES87: pg 122). 
d. Slope Calculations 
Elevation is a function of UTM coordinates, h(x,y). The gradient of h 
is a vector in the ground (X-Z) plane that points in the direction of greatest increase 


of altitude. 


Vh=} ody/ox, dy/dz (6216) 


This model is not so concerned with the direction of the gradient vector as with its 


magnitude and the magnitude of the slope angle y, which is the angle between a tan- 


gent to the elevation function and the X-Z plane. 
1/2 


w, =tan! | (ay/ax 2+ (dy/az ) (3-17) 


Fortunately, it is not necessary to calculate the slope angle directly. It can be calculat- 


ed from the terrain polygon patch surface normal unit vector N which is already avail- 


able for each terrain polygon from the lighting model calculations. Call yy, the angle 
between N and the X-Z plane, which is also the map ground plane. Since N, with 
components X,, yx, Z,, 1S perpendicular to the terrain polygon, | Wn eal WV, l=n/ 
jaa Now wy, = tan! (yy / ( aa oe aS ), and since tan( x / 2 — 8 ) = cot( 8 ) and 
tan(8)=1/ cot(@), then 


Wh SUM tae a eS (3-18) 


Jae, 


In the vehicle simulator, this result is produced by _ the function 


convert_normal_to_slope which returns Vi, in radians. 


If the surface normal of the terrain polygon is not readily available 
(perhaps because vertex normals are being used), the effective slope of the vehicle 
can be calculated from its pitch and roll. These body angles are used to calculate the 
world coordinates of a body normal, a normal vector which points out the roof of the 


vehicle, using another math function transform_body_to_worid, shown in Figure 3-4. 


float normal([3], slope; 

transform_body_to_world( platform->cse, 
platform->base_plitch, 
platform->base_roll, 
0.0, 1.0, 0.0, 


&normal[0O], 

&normal{t], 

&normal[2] ); 
slope = convert_normal_to_slope( normal ); 





Figure 3-4 Calculating Effective Slope Using Platform Orientation 


Finally, vehicle pitch alone can be used as effective slope to limit 
speed, since, stability factors aside, pitch angle is the slope resistance the engine 
must overcome. 

e. Effects of Slope 

Instead of directly modeling the effect of acceleration forces on a vehi- 
cle due to gravity when travelling on sloping terrain, the model assumes that the traf- 
ficability of sloping terrain limits vehicle speed before engine power would be 
insufficient to maintain a set speed. Maximum vehicle speed is limited by a slope 


governor that decreases maximum speed as a function of slope. This slope governor 
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function is shown in Figure 3-5 where MAX_GNDSPEED is the maximum speed a 


Speed (MPH) 
MAX_GNDSPEED 


MIN_MANEUVER_SPEED 





ibs Slope (degrees) 


Figure 3-5 Slope Governor Function 


vehicle can achieve on level ground and MAXSLOPE (27°) is the maximum slope tra- 
versable by the vehicle. Since limited speed could go to zero in untrafficable terrain, 
the vehicle would be stuck, unmovable, if it ever entered a NOGO terrain patch. A 
low "maneuver' speed is allowed for the driver to carefully and slowly work his way 
out of such a situation. 

f. Suspension Oscillation - “Bounce”’ 

When a vehicle crosses a bump or other change in terrain slope, it 
induces an oscillation in the spring-mass suspension system. This oscillation 
continues until it is damped by the shock absorbers and friction of the vehicle 
Suspension moving parts. This motion can be quite difficult to model due to the 
complex geometry of a vehicle suspension system. However, by limiting oscillations 
to changes in vehicle pitch angle only, this motion is easily modeled as simple 
damped harmonic oscillation along a single axis (the vehicle pitch angle) as shown in 


Figure 3-6. This transient pitch is then added to the base vehicle pitch caused by the 


ue 


slope of the terrain. Two additional fields in the vehicle data structure are created to 


handle this effect, bounce_amplitude and bounce_time. 


Pitch Amplitude 


i 


Transient Pitch Offset 





Figure 3-6 Damped ‘“‘Bounce”’ Oscillations 


The equation for damped harmonic motion [MARION70 :pg 371] is: 


yY=Y, e Bt cos( Mt +6 ) (3-19) 


u u 


amplitude — oscillation 


where B = b/ 2m, b is the damping force, m is the mass of the vehicle, and @, is the 


= qm. Choose a time 


frequency of undamped oscillations of the system. Assume 0), " 


constant t, which is equal to the time interval when amplitude of the oscillations has 
decreased to 1 / e of its original value, which is tT = 2m / b. Equation (3-19) can then 
be written as: 

y=ly,-(y, *dt/t)] * cos( wat) (3-20) 
If the displacement y is the suspension travel at the front wheels then 6 = 


tan“ y / wheelbase). For relatively small displacements, the damped harmonic oscil- 


lations can be calculated directly using the pitch angle 8 and (3-20) becomes: 
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Gamo (0 diy ce CON Tt) (3-21) 
This can be broken up into two code steps for each cycle of the update loop: 
1) Calculate the current angular oscillation value. 
bounce_pitch = bounce_amplitude * 
cos( OSCILLATION_FREQUENCY * TWOPI * total_time ); 
2) Calculate new bounce amplitude based on damping effect. 
bounce_amplitude = bounce_amplitude - 


( bounce_ampllitude * dt / DAMPING_TIMECONSTANT ); 
With DAMPING _TIMECONSTANT set to ( 1 - l/e )/T. 

Empirically, equation (3-21) and its code can be shown to approxi- 
mate the results of (3-19). Considering a typical case’ and comparing just the de- 
cline in amplitude after 3.0 seconds, equation (3-21) yields 5.5° (converted from y 
displacement), while the code gives 4.8°. Only a small part of this difference (app 
0.1°) comes from oscillating the pitch angle directly instead of oscillating the displace- 
ment and then converting, 5.5° versus 5.6°. The total error is small enough that 


"tuning" the constants can bound this error well within the difference detectable in a 


moving visual simulation. 


6. Simulation Time Interval 

The model time interval, or dt, using Leibnitz notation, is the elapsed time 
required to complete one processing loop in simulation time. Since the rates of 
change of most of the processes are non-linear, the linear approximation used is only 
a good approximation if dt is small, « 1 second. The second problem that results if dt 
is not small enough comes from delayed control feedback. For example, if steering a 
vehicle in a turn and df is of the order of 1 second then the driver will tend to over- 
shoot control corrections, making it difficult to steer onto a desired course or avoid ob- 


stacles. This lower bound is due to control response and depends on many factors, 


q For DAMPING_CONSTANT = 3.0, dt = 0.25 seconds, wheelbase = 2.0 meters, initial displacement of 5 meters = 15 degrees, and 
total time = 3.0 seconds. 
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including platform velocity, control responsiveness, complexity of maneuvers, etc. Re- 
sponsiveness for an aircraft travelling at hundreds of MPH must be greater than for a 
ground tactical vehicle travelling cross country at speeds typically < 25 MPH. For 
such ground vehicles, a subjective lower bound appears to be 3-4 frames or cycles per 


second. 


7. Paths 

Paths in APS resemble the military concept of a "route" with an SP (Start 
Point), RP (Release Point) or goal, and a CP (Check Point) at turning points or crit- 
cal points. Figure 3-7 shows the path data structure. The SP of the path is its first 
point and the RP is the last point on the path. Each platform data structure 
(Appendix A) contains a pointer to a path and a pointer to the next point along the 
path. Path manipulation routines are contained in module path.c. 

Paths are created and maintained separately from platforms. When a vehi- 
cle is "assigned" a path to traverse, a copy of the path is made for the platform and a 
pointer to the platform is added to the list of platforms assigned to that path. Thus 
several platforms can be assigned to traverse a path and navigate along it indepen- 
dently. Also, if a point on the original path is altered, all affected platforms can be no- 
tified. On the other hand, if a platform must deviate from the path to avoid an 
obstacle, intermediate points can be inserted in the platform’s copy of the path with- 


out affecting the orginal. 
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Figure 3-7 Path Format 


A platform being guided by an external agent by receiving one point at a 
time is actually following a path that consists solely of a periodically updated goal. 
As new guide points are received, the goal point is replaced. The autopilot module 
can then navigate a platform along a path by heading successively toward each point 
on the path list. Figure 3-8 shows a tank approaching the goal point, which is drawn 
as a tall, pyramid marker on the terrain. The paths are maintained as a linked list 
managed using four global variables: 

pathilst - pointer to first path on path list. 


pathilstend - pointer to last path on path list. 


Si 





a 


@ 


Ya 

ag 
x & 
2 A 
bad + 


Figure 3-8 Driving a Tank Toward Its Goal 
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numpaths - number of paths currently on pathlist. 

path_pickid - unique identifier for graphics picking. 

Path manipulation is accomplished by selecting the "PATH OPERA- 
TIONS" entry in the main menu. The path operations menu is then constructed and 
displayed, providing for the selection of up to four functions: 

1 - Display Paths - ON/OFF 

2 - Construct a Path 

3 - Delete a Path 

4 - Assign Vehicle to a Path 
The first option toggles the display of paths on the 2D terrain map. Figure 3-9 shows 
the display used to manipulate paths. Paths are displayed by default but may be 
turned off to reduce screen clutter. Menu option 3 is only presented if there is at least 
one path defined. Option 4 is only presented under the additional condition that at 
least one platform is defined. At present, all platforms except FOGM can be as- 
signed to a path. A path, once defined, is stored in a file containing all currently de- 
fined paths. When APS is started, it searches for a file "“aps_paths.dat” in the 
following directories, in order: the current (default) directory, the directory containing 
the APS executable, and the "DTED" directory. If the file is found, APS loads the 
paths it contains. Each time a path on the path list is created or destroyed, the file is 


updated. 


8. Guidance States 
The current control state of each platform is reflected by the combination of 
two fields in each platform record: 
control - MANUAL or AUTOPILOT 
ext_guidance - ON or OFF 
The slot ext_guldance determines whether platform guide points are taken from in- 


coming message or an assigned path. The slot control determines whether course 
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Figure 3-9 Terrain Map Used for Path Planning 
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commands are calculated by the autopilot or are provided from the vehicle controls 


(dials or the mouse joystick). 


9. Autopilot 

The autopilot determines the commanded course and speed for each local 
platform that has its control field set to AUTOPILOT and has a path defined. Since 
external guidance messages update the platform’s local path record, the autopilot 
functions irrespective of the source of the path data. The autopilot calculates an azi- 
muth to the current guide point. The current guide point is automatically updated to 
its successor on the path (if there is one) when the platform is within VICINITY 
meters of the way point. If the platform gets within ARRIVED_DISTANCE of the 
guide point then the guide point must be the last point on the path, 1.e. the path goal. 
If so then the autopilot applies the brakes to bring the platform to a halt without over- 


running the goal. Figure 3-10 shows the relationship of these distances. Precise 


Guide Point ARRIVED 
DISTANCE 





Figure 3-10 Autopilot Control 


control would require both these distances be variables that are a function of the plat- 
form’s speed, instead of constants, so that a platform starts to brake or turn in the 
time necessary to stop or turn exactly over the guide point. This level of precision 
would be necessary to navigate a platform through a field of obstacles and would re- 


quire projecting ahead the platform’s location so as to issue the proper commands at 
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the correct time. However, the simpler algorithm presently used is adequate to halt a 
platform travelling at maximum ground speed (MAX_GNDSPEED) before reaching 
the goal. 


B. PATH PLANNING 


1. Introduction 
The path planning process for this study simulates the actions of the vehi- 
cle commander in planning paths, and issuing waypoints for a controlled vehicle. The 


commander starts out with the following facts: 


¢ Which vehicle is being controlled. 

¢ Start point and goal locations are known. 

¢ A terrain map of the region to be traversed is available. 

¢ The terrain map contains cost of traversal information for the region. 
¢ Vehicle speed. 

¢ Vehicle course. 

¢ Vehicle guidance mode. 

¢ Vehicle location in UTM coordinates. 

¢ Current simulation time. 


The commander uses this information to plan a path to the goal, selecting 
the quickest path between the start point and the goal point. In selecting a path, the 
commander chooses prominent terrain features as guiding waypoints for the driver. 
Once the path is selected, the commander issues commands to the driver to proceed 
to the first waypoint as indicated by the commander. The commander continues to is- 
sue new waypoints as the driver pilots the vehicle close to the last waypoint. As the 
simulation continues, the commander needs to be informed of changes to the vehicles 
Status as indicated here. 


¢ Vehicle ID. 
¢ Vehicle speed. 
¢ Vehicle course. 


¢ Vehicle guidance mode. 
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¢ Vehicle location in UTM coordinates. 
¢ Current waypoint location in UTM coordinates. 


2. Path Planner Control Program 

The path planning simulation of the commander is divided into two major 
areas, the overall controlling program and the actual search algornthm that does the 
path planning. The term path planner is used to describe the combined AI processes 
that make up the AI simulation of the path planning commander. The path planner is 
kept separate from the graphics simulation of the vehicle and implemented on the 
Symbolics AI workstations. Two reasons for this are: first, a great deal of path plan- 
ning work done at the Naval Postgraduate School is done using AI workstations, and 
second, a substantial amount of the program code produced is done in LISP and Pro- 
log that can be easily ported between the different AI workstations. 

The path planner control program is separated from the actual search por- 
tion of the path planner for three reasons. The first is to allow modularization of the 
code. The communication costs associated with this approach do not appear to over- 
ride the benefits of being able to substitute different search algorithms. The second 
reason for the separation was to allow the path planner control program the exclusive 
use of a workstation. Expert system shells require considerable system resources, 
and it is felt that the overhead of running the expert system shell would put an exces- 
sive load on a single workstation when combined with running real time path planning 
searches. Finally, this separation should allow more than one search program to 
work simultaneously. 

a. The Expert System Shell 

High turnover and short learning curves predominate much of the frus- 
tration associated with thesis work. Therefore, since one of the major goals in this 
Study was to provide a test platform that could be used to study the relationships as- 
sociated with the application of artificial intelligence techniques to the control of au- 


tonomous vehicles, it would be advantageous to have the path planner controller 
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written in a high level symbolic programming language. The use of such a language al- 
lows a researcher to examine problems at a much higher level of abstraction than with 
LISP or Prolog. 

One of the criteria in the selection of an expert system shell was the 
desire to have the path planner control program continuously monitor the knowledge 
database and react to changes therein. Forward chaining control strategies facilitate 
this continuous flow within the rule based system by simply keeping fresh facts as- 
serted. In ART and KEE, the forward chaining mechanism is self contained in the in- 
ference engine of the shell. There are forward chaining control implementations 
written for both LISP [MCNKLE&88] and Prolog [ROWES88], but abstracting the re- 
searcher away from the mechanics of forward chaining produces code which is easier 
to understand. 

ART was chosen over KEE in part because it appeared easier to ex- 
amine the workings of the rules in ART. ART allows direct manipulation of the rules 
through Symbolics’ ZMACS editor, and through the use of ART’s ability to watch and 
record the firing of rules, and the assertion and retraction of facts. 

b. How ART Works as a Process Controller 

ART is a rule-based, expert system shell, containing the ability to 
forward chain and backward chain. The principle inference engine is the forward chain- 
er. As stated in Chapter II, an ideal inference engine within a shell would provide an 
uncluttered view of the rules and knowledge base used in a problem. In reality, there 
are inherent limits on the inference engine implemented within ART. One important 
limit is that an artificial structure and order are imposed on rule firing. A simple exam- 
ple of this is the difference between the firing of two rules that require identical pre- 
conditions. One rule must fire first. The engine must decide. The choice could be as 
simple as choose the rule that appears first in the program structure, or choose the 
shortest rule. And though the choice may be arbitrary it must be consistent. ART ap- 


pears to choose the first rule in the program structure. 
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(1) Rule Structure. ART’s rule structure provides a straightforward 
way of declaring the complete predicate logic for a given rule. A sample rule extracted 
from the path planner control program is presented in Figure 3-11 below. The left side 
of the rule contains the preconditions necessary for the rule to fire. The right side of the 
rule carries out actions. These actions can be controlled by binding temporary facts and 
by examining states through the use of conditional statements. The parts of the rule 
are clearly shown in Figure 3-11. Here the rule is fired when the fact (menu one) is 


asserted. The nght side of the rule can request the operator to perform some action 


(defrule MENU1 
(schema sym 
(one ?s1) 
(two ?s2) 
(three ?s3)) 
2a <- (Menu one) 
=> 
(printout t t "Where is the path planner located?") 
(printout tt “Your choices are the following, chose one by it's letter. * 
t°a” 281 
t"b* ?s2 
tec 7s3 
t "NOTE--Please ensure that the path planning software is running’ 
t) 
(bind ?b (read)) 
(if (or (eq 7b ‘a) 
(eq 7B A) 
then 
(assert (sym-link ?s1) 
(menu two) 
else 
(retract 7a) 
(assert (Menu one)) ) ) 
) 
(retract ?a) 
) 





Figure 3-11 MENUI1 Code Fragment 
such as choose the Symbolics machine where the search control program resides. The 


Operator’s response is then checked to ensure a valid response, and facts are asserted 


that enable the Symbolics communications start up rule to fire and_ start 
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communications with the appropriate Symbolics workstation. Of special note here is 
that a fact in ART must be retracted before it is reasserted. If the fact is asserted 
before it is retracted, the assertion will be lost. This is because ART keeps only one 
copy of identical facts. The Path Planner Control Program contained in Appendix B 
provides a more detailed look at the code. 

(2) Continuous Forward Chaining. A rule firing control mechanism is 
needed that allows the path planner control program to continuously monitor the 
knowledge base and the communications sub-process. This is accomplished with 
continuous forward chaining by cycling through a base set of rules. The rules chosen 
for this cycling are the interface with the vehicle clock and the calls to the system’s 
communications ports. These rules are selected because they are the most likely 
routes for new facts to enter the knowledge base of the commander. The Symbolics 
read-char-no-hang stream read method is used in the communications rules to ensure 
that the communications calls do not wait if there is no data on the lines. Rule cycling 
begins when a rule has met all of its enabling preconditions. A rule fires when all of 
its enabling facts are met. The rule check-comm-links-irls retracts its enabling fact, 
and asserts the facts (check-comm irls), (check-comm sym), and (clock-update yes). 
Order of assertion is important here because the last fact asserted will be pursued 
first, as explained in Paragraph c. below. If no information is available from the IRIS 
communications link, the clock is updated, the Symbolics’ communications link is 
checked, and finally ART cycles back through the checking of the IRIS 
communications link. 

(3) Rule Precedence. Actions by a human commander are taken 
according to some precedence or order imposed by the commander’s judgement. It is 
desired to duplicate the human’s ability to judge and separate actions that need to 
happen immediately from those that could be postponed. Assigning rules an order of 
precedence allows more important rules to be examined first. Rule precedence is 


accomplished by the use of ART’s salience function. Salience values are from -10000 
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(lowest precedence) to 10000 (highest precedence). A rules salience value is 
assigned at compile time. If the rule’s salience is not declared, a value of O is 
assigned. Rules of the same salience are loaded onto a stack as they become ready to 
fire. Rules thus grouped are fired according to their salience value first, then 
according to their position on the stack. It is useful to think of ART as having a 
Separate stack for each salience value, and always firing rules off the stake with the 
highest salience value. At each level of precedence, the rule loaded to the stack last 
is fired first. This provides a mechanism to mimic the human ability to pursue what 
should be done first. Rules must be written such that more important things have 
higher saliences than less important things. The consequences of this stack action 
effectively imposes a most recent fact following algorithm. A side effect of a most 
recent fact following algorithm is that it can lead to indefinite postponement of rules. 
This can happen in two different ways. First, if high precedence rules are continually 
added to the agenda stacks, low precedence rules will never fire. A second and more 
subtle way a rule could be indefinitely postponed is by asserting a fact that activates 
a rule of the same precedence as the postponed rule. Since all newly asserted rules 
are loaded to a stack, the most recent rule is looked at first, thus postponing the older 
rule. This indefinite postponement is easily handled in Prolog by using an assertz 
command. Using ART, the programmer must control rule firing by sequentially 
activating rules, and ensuring that all sequences of rule firings lead back to the lowest 
level. 

(4) LISP Calls. LISP calls are used where it is more convenient to 
perform an action on LISP data structures or to use existing LISP functions. LISP 
calls can be made only on the right hand side of rules, and are delineated by #L 
immediately before the LISP code. ART can make direct use of LISP symbols and 
values, but is clumsy at manipulating LISP lists. Therefore, LISP lists are converted 
to ART facts and schemas that use relations within ART to link related facts. An 


example of this, in Appendix B, is the rule process-waypoints. In this rule, the 
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incoming waypoints are stored with the vehicle and their sequence number from the 
list they came from. ART also fails to recognize the strings produced by calls to the 
LISP communications packages. Here Common LISP provides the intern function to 
convert a string into a symbol. This symbol 1s then fed to ART. As can be seen in 
Figure 3-12 below, the intern command requires a prefix that designates which 
Symbolics package the LISP function is defined in. The ART package does not have 
all of the Symbolics’ Common LISP functions available. 


(bind 7b #L(sci:intem (scl:send talk-i :check-iris 3))) 


(if (eq 7b '>>>) then 


Figure 3-12 Code Excerpt from the Rule read-update 


3. Path Planning and Search Algorithms 
The second portion of the path planner is the search algorithm. The require- 

ments for the algorithm are that it accept as input the following data: 

¢ Start point 

¢ Goal point 

¢ Vehicle ID 

¢ UTM coordinates of the lower left hand corner of the 10 KM grid window. 
The output requirements are waypoints passed individually with the corresponding 


sequence number and vehicle JD. 
a. Search Region Representation 
Planning a path across real or simulated terrain requires some criteri- 
on be established that will allow the path planner to choose between routes. Slope is 
a common terrain feature used as a simple distinguishing factor [ROWE&88]. The 
greater the slope, the greater the cost of traversal. This criterion has some interesting 
properties that are not in accord with the physical environment. In APS, effective 


slope is an absolute value independent of the direction of traversal. In traversing an 
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actual physical region a given incline has varying degrees of relative slope depending 
on the traversal angle. Since the major goal in this study is to build a test platform 
that would allow the testing of search algorithms and their interfaces with simulated 
vehicles, this discrepancy is accepted in the interest of simplifying the problem. An in- 
teresting result of this simplification is that bidirectional searches can be performed, 
because the cost of traversal is independent of the direction of travel across a given 
region with a given slope. 

Discrete geometric cells were used because of the simplicity of 
conversion from the graphics elevation data to the slope data used by the wavefront 
path planner. The use of the wavefront search technique was based on _ the 
construction of the elevation and slope data files and the ease of implementation of 
the wavefront algorithm. The slope data files produced by Felhoelter’s methods were 
designed to contain all of the information about a given search region [FELHOE88]. 
This information included the boundary information that ensured the search algonthm 
would not overflow the search region. This boundary information was otherwise 
unrelated to slope information of the region. The stripping off of this boundary 
information was trivial and could be accomplished while building the slope files or 
after they were complete. However it became apparent that the use of slope data 
files containing one by one to ten by ten kilometers of slope data would prove difficult. 
Using files built in this manner would have required the use of 1225 to 625 separate 
slope data files for a 35 KM by 35 KM map that covered the same region as the map 
used by the IRIS based vehicle simulator. It would have also required either 
predefining the area to be searched or some other way of selecting the appropriate file 
for a given run. Initially a 35 KM by 35 KM slope data file was used, but it was found 
that the time to read in the data took as long as six minutes. This long read-in time 
occurred because each record of the file had to be read in sequentially until all of the 
data for a given map was read in. This read-in time was reduced to one minute by 


converting the text file to a binary file and using the Symbolics LISP file-position 
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function, which is Symbolics’ equivalent to the Iseek function of C. Finally, the slope 
files were recomputed using the graphical methods developed on the IRIS 
workstations. This was done because the methods used by Felhoelter produced 
significantly different slope data than that produced on the IRIS workstations. This 
difference appears to be based on the fact that the vehicle simulator uses the slope 
calculated from the lower left triangle of a one hundred meter square in the graphics 
simulation. These triangles were used because they form the planar surfaces used in 
the graphical displays on the IRIS workstations, and the drawing routines provide 
normals to the surface from which slope can be easily calculated. These methods 
were described earlier in this chapter. The only significant difference between the two 
methods is when the slope calculations are performed. The slope information for the 
Symbolics processes is calculated before the simulation is begun, while the slope 


information is produced at system run-time by the vehicle simulator. 


C. AUTONOMOUS vs. MANUAL CONTROL 

The guidance and control states of APS have been previously described. What 
follows contains a fuller explanation of what is involved in the transition between 
these states. The states were designed to be as independent and flexible as possi- 
ble, to allow switching in and out of autopilot control while being guided by an exter- 
nal agent and, conversely, to allow switching external guidance on and off while 
remaining under autopilot or manual control. Ideally, the source of external guidance, 
human or AI agent, would be transparent to the guidance system. Unfortunately, the 
methodology used for human control introduced asymmetries into the design. An ex- 
ternally guided vehicle is controlled by a remote human path planner on another graph- 
ics workstation differently than it is guided by the remote AI agent. The human 
commander designates a path for a remote platform vehicle just as if it were a local 
platform. The path is then transmitted across the network in its entirety. Thereafter 


the vehicle driver navigates as if the path had been generated locally. On the other 


hand, the AI agent transmits one path point (guide point) at a time, successively up- 
dating them as the vehicle gets near. The source of this lack of symmetry lies in the 
greater functionality of the AI agent. It was designed to calculate a new path if the 
controlled vehicle encountered unforeseen obstacles or deviated too far from the calcu- 
lated path. This cannot be done in advance. This dual role of global and local planner 
was never envisioned for the remote human commander except in the case of replac- 
ing one global path with a new one. In essence then, the external guidance state be- 
comes one of exclusive AI agent control and the methods used for the transitions 
back and forth between external and internal guidance are designed to accommodate 
the different models of guidance and preserve the transparency to the rest of the vehi- 
cle simulator. 

A platform’s external guidance can be toggled ON or OFF either locally by a 
popup menu selection from the driving menu or remotely by network message. This 
network message iS generated by a remote human commander making the same 
menu selection as would the local operator. If the selection is made locally, the mode 
transition is made. If the selection is made remotely, the message is transmitted. 
Actions on the local platform are the same regardless of the source of the command. 
At present, no authentication or permission system is used, nor is there a local lock- 
out or override provided. 

External Guidance OFF --> ON causes the following actions: 

1) Set ext_guidance toggle ON. 

2) Send an INITIALIZE control message to the AI agent containing the UTM 
coordinates in meters of the origin of the current ten kilometer box, vehicle identifier, 
start and goal points of the path, and current simulation time (If no AI agent is con- 
nected the message is discarded). Note that the start point sent is the platform’s 
current guide point which may not be the SP of the originally assigned path. If the 
platform had partially navigated a path under internal guidance, then the guide point 


will be the next point in the remainder of the path. 
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3) Set up the platform to receive guide points by making the platform’s current 
location its guide point and deleting the remainder of its path. This is done so that the 
autopilot, if engaged, will simply bring the platform to a stop instead of heading out di- 
rectly for the goal. The portion of the path traversed so far is preserved on the front of 
the list. 

4) Finally a position update message is sent over the network on both broad- 
cast and stream channels. Currently it is this UPDATE message, with its guidance 
field set to ON, which triggers the AI agent to calculate an optimal path based on glo- 
bal terrain cost data. However, there is nothing in the vehicle simulator to prevent 
the AI agent from choosing the start and goal points by itself, sending a message to 
turn guidance ON, and then sending guide points from a calculated path. 

External Guidance ON --> OFF causes the following actions: 

1) The platform’s external guidance flag is set to OFF. This causes any incom- 
ing guide point messages for this platform to be ignored. 

2) The platform’s path is deleted. 

3) Its original assigned path, if any, 1s reloaded. 

4) The platform’s guide point is set to the point on the orginal path closest to 
the platform’s current location. In this way, a platform taken off external guidance af- 
ter navigating a portion of a path would not go all the way back to the start point, but 
can complete the remainder of the path. Note that the closest path point is not neces- 
sarily the best path point pick to minimize travel time or some other performance mea- 
sure. Locating the best path point is a non-trivial problem in itself. In some cases 
the simple method used will guide the platform back to a previously passed path point 
or directly to the goal point. Generally however, when assigned a path with many 
fairly short segments, backtracking and loss of time will be limited to one half the 


length of the current path segment. 
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5) Finally, a position update message is sent over both broadcast and stream 
channels. The guidance field of this message reflects its new state and directs the AI 


agent to stop sending guide points. 


D. COMMUNICATIONS 

The amount and sequence of data that must be passed over the network is de- 
termined by the functions to be performed. For communications between vehicle sim- 
ulators, sufficient data is needed to display the platform on a remote simulator as well 
as model its movement. Information flow with the AI agent is determined by the divi- 
sion of labor between the vehicle simulator and the commander, human or machine. 
Updates are sent between vehicle simulators or to the AI agent only when a state 
variable such as speed, course, weapon firing, etc., changes. In general, in communi- 
cating with other vehicle simulators on the network, the vehicle simulators PUSH in- 
formation over the network using broadcast datagrams to any others who might be 
listening. Only upon initialization does the system poll for a response. 

There are usually several methods to chose from when communicating between 
applications over a LAN. In the case of the APS development environment, TCP/IP 
supports byte streams, which require dedicated connections, and datagrams, which 
may be connectionless, and even addressless in the case of broadcast datagrams, or 
may be sent between connected hosts. The vehicle simulator’s use of a PUSH broad- 
cast system to communicate with other vehicle simulators is adequate for the amount 
and types of messages needed by that portion of APS. It would have been simpler if 
this same approach could have been used for communicating with the AI agent. 
Broadcast datagrams provide for reliable’ transmission of discrete messages over a 


LAN. This means that specific addresses need not be hard coded or determined at 


1Datagrams are not usually considered “reliable” because there is no receiver acknowledgement. If communication between hosts 
is entirely intra-network then the underlying protocol, in this case Ethemet’s CSMA/CD, guarantees delivery to each host and, 
barring buffer overflow or process termination, the message will reach each process properly attached to the addressed port. 
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run time and that each read will return zero or one complete discrete message 
(provided the message fits within the network maximum size). However, this proved 
not to be feasible primarily due to the limitations of the Symbolics’ implementation of 
support for TCP/IP network services. The only arrangement that worked during this 
research was a pair of halfduplex stream connections, with the further limitation that 
the vehicle simulator must act as the server and the Symbolics as the client. For con- 
sistency, communications between AI processors also use stream connections. 

The only remaining design decision for the vehicle simulator end of the communi- 
cations link was then whether to have the simulator poll the incoming stream connec- 
tion for input using a non-blocking read or to spawn a sub-process to continuously 
monitor the connection and communicate with the main simulator process through 
semaphores and a shared memory buffer to hold messages. 

A separate subprocess carries the additional complexity of implementing sema- 
phores and shared memory plus the computational overhead of a context switch. Al- 
so, during development, when system aborts are common, special care must be taken 
not to leave orphan subprocesses when the main process terminates. The main ad- 
vantages are immediate response to incoming messages and message preprocess- 
ing. The subprocess issues a normal blocking read on the connection, which sleeps 
until input is present. This is more efficient than constantly polling. The second plus 
is the ability to respond immediately to some query while the main processes may be 
tied up in computation and graphics processing. 

The polling approach is simpler. In fact, in APS even the initial acceptance of a 
connection request is done by polling. On a single processor system, one CPU still 
must run both the main and subprocesses so no real time is being gained by running 
them in parallel. There may be some concem that the input buffer may overflow 
between polls, which in APS happen once each drawing cycle. However, under UNIX, 
the receive buffer can be made practically as large as desired (currently 40K bytes) or 


at least as large as the shared memory buffer is likely to be, so the nsk of overflow 
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between cycles is the same. The system network daemon basically does the same 
job as the subprocess, and hopefully, it is more efficient at it than user written code 
would be. Tests using dummy AI agent programs which send messages at ten times 
the normal rate have not produced evidence of a lost message. 

Communications with the Symbolics AI agent are performed as follows: 

1) Upon initialization, the vehicle simulator establishes a stream socket, sets it 
to non-blocking operations, increases its receive buffer size, and creates a connection 
queue as a Stream Server. 

2) Thereafter, during each graphics cycle, the socket is polled by issuing a non- 
blocking ACCEPT command. If a stream client, in this case the Symbolics, is waiting 
for a connection, two stream sockets are cloned, one for receiving messages from the 
Symbolics and a separate one for sending messages to it. 

3) If a working connection is established, then a non-blocking read is issued on 
the receive stream socket. Messages from the AI agent, comprised of character 
strings with punctuation character delimiters are extracted from the stream and re- 
turned as whole messages to the simulator which takes the appropriate action. The 
specifics of how this is implemented are contained in Chapter IV. If the stream con- 
nection is broken by the AI agent, then a flag is set and the system returns to polling 
for a connection instead of polling for data to read. 

At the Symbolics AI agent, the path planner needs to monitor the progress of 
the vehicle, independent from the vehicle simulator updates. This means that calls to 
the communications system can not be allowed to wait for data. For this reason com- 
munications at the Symbolics AI agent is done using the read-char-no-hang method 
to read the input stream. This allows reads from the I/O stream to return nil. 

Messages are identified and delineated by non alphanumeric characters. Non al- 
phanumeric message delimiters were chosen to reduce the chance of processing par- 
tial messages. This could occur if the first part of a message were lost over the 


network. It is assumed that a properly delineated message is complete and correct. 


49 


The use of a data stream requires that the formats of the messages be known in 
advance, and that each message be identified as to type. This is accomplished by the 
use of non alphanumeric delimiters as mentioned above. A further precaution that en- 
sures messages are not lost forever should one message arrive without its leading 
delimiters is the use of different length delimiters on the front and back of messages. 
The front delimiter is longer than the back delimiter. This is done to prevent a mes- 
sage that has lost its front delimiter from starting a cycle of reads that could pass 
over the correct first delimiter. The algorithm that receives the messages on the Sym- 
bolics workstations checks for the first delimiters, and then reads in a prespecified 
number of characters, based on the message type. The last few characters make up 
the ending delimiter. It should be noted that the sending process supplies a null char- 
acter between messages. If the ending delimiter were the same length as, or longer 
than the beginning delimiter, the ending delimiter could be interpreted as the begin- 
ning. Since the rest of the message is not evaluated untl the ending delimiter is 


checked, message traffic could remain out of synchronization indefinitely once broken. 


E. PERFORMANCE MEASURES 

In order to make quantitative comparisons among path planning algorithms or 
human-machine control arrangements, some numerical figure of merit must be cho- 
sen. For tactical vehicles travelling cross-country, some candidates are: transit time, 
fuel consumption, enemy exposure, weapons line-of-sight, etc. In this study transit 
time was chosen because it can be tied directly to the terrain data base and platform 
characteristics. 

For each platform experiment or trial, there is a global planning time and a 
transit time. In a sense, the planning time represents a fixed investment cost and 
transit time operating cost. An experiment may compare total time (planning and 
transit time) or analyze them separately. As an example of the type of trade-off 


study that might be made, consider the current path planning algorithm used. Such a 
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wavefront or breadth-first algorithm may not represent the fastest way to produce an 
optimal global path. However, its nature as a neighbor-based algorithm means that 
each path step is calculated only on LOCAL cost data. Then, assuming the agenda is 
preserved, when a small piece of the data changes, such as the discovery of an 
obstacle, only a small region need be recalculated. Its overall performance in the 
presence of constantly changing local data might be superior. 

This research makes no attempt to produce a definitive measure of effective- 
ness. Rather a mechanism is sought that will provide a basis of comparison for oth- 


ers to use in measuring the effectiveness of path planning systems. 


F, SUMMARY 

This chapter provides an examination of the source, thought process, and evolu- 
tion of the design of APS. The development of the vehicle motion model and control 
response of the vehicle simulator are discussed along with the knowledge base of the 
rule-based path planner and path planning algorithms. This chapter concentrated on 


the why. The next chapter will delineate the how. 
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IV. SYSTEM DESCRIPTION 


This chapter describes how the methodology and algorithms were implemented, 
including the function and structure of some of the main programs and rule sets. Data 


structure definitions along with some code listings are contained in Appendix A. 


A. TERRAIN DATABASE 

APS uses terrain data that is a subset of a vegetation and elevation database in 
12.5 meter increments for an area of Ft Hunter Liggett, California, provided by 
CDEC. This database is preprocessed into 100 meter resolution data by sampling ev- 
ery eighth point and then stored in a separate file that is read by APS. Each data 
point is 16 bits (2 bytes). The 3 most significant bits form a vegetation code which 1s 
used to color terrain polygons in a shade of green for the 3D view. If the vegetation 
code indicates light or no vegetation, or no vegetation data is available, then the ter- 
rain polygon is colored according to its elevation using the currently designated color 
map, usually shades of brown. The remaining 13 bits contain the elevation in feet. 
This elevation is used to draw the 3D terrain, calculate normals for the lighting model, 
and calculate slope used by the path planning cost function. 

APS is currently limited to the 35 KM by 35 KM area for which preprocessed 
data is available. In UTM 10 meter grid coordinates, this area extends from 
1OSFQ41006000 to 10SFQ77009500. A basic terrain surface patch is formed by the 
four elevations of the vertices of a 100 meter square. These points are not 
necessarily planar. Since the IRIS cannot quickly render filled non planer polygons, 
this polygon is divided along a NW to SE diagonal into two planar triangles which are 


rendered as filled shaded tangles. This basic terrain patch is shown in Figure 4-1. 


Sy 


The lower left (SW) triangle is called the /ower triangle and the upper mght (NE) 


triangle is the upper triangle. 


upper tangle 


lower triangle 





Figure 4-1 Terrain Patch 


The elevation of each triangle vertex is stored, along with its X and Z offsets in 
a floating point array (the upper left and lower night points are duplicated) consisting 
of 72 bytes (3 X 6 X 4bytes) per 100 meter square. In addition, a surface normal 3D 
vector is calculated and stored for each triangle. One square kilometer of terrain data 
thus consumes 9600 bytes (10 X 10 X 96bytes). The entire 35 KM by 35 KM area 
consumes over 11 Mbytes of memory. To maintain performance, only the vertex and 


normal data for a 10 KM by 10 KM area selected by the user are kept in memory. 
B. VEHICLE SIMULATION 


1. Capabilities 
The capabilities of the Autonomous Vehicle Simulator include: 


¢ Acceleration due to changes in engine throttle (thrust). 
¢ Deceleration due to coasting and braking. 


¢ Change in vehicle pitch due to acceleration or braking proportional to the mag- 
nitude of the change of velocity. 


¢ Vehicle roll due to centrifugal force while turning. 
e Linear steering controls with exponential steering response. 


¢ Damped vehicle oscillations due to changes in vehicle pitch as vehicle travels 
over varying terrain. 


¢ Change in vehicle velocity due to terrain slope. 
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¢ An autopilot that will navigate a platform along a designated path. 


¢ The ability to handle vehicle control inputs from either local driver controls, lo- 
cal/remote autopilot steering commands or remote autopilot/commander path 
commands. 


¢ Models multiple vehicles, with selectable independent views from each vehicle 
representing weapon sights, commander’s station view, etc. 


¢ Multiple independent viewing axis and viewing positions. 


¢ Multiple independent weapon system axis maintained to provide for stabilized 
weapon/sighting systems. 


¢ Utilizes graphics hardware for fast coordinate system transformations. 


¢ The ability to sight, range, and fire weapon systems, including stabilized 
weapon systems. The following platforms and weapons are implemented: 
tank with main gun SABOT and HEAT rounds, open jeep, closed top jeep, 
TOW jeep, truck, Cobra attack helicopter with TOW weapon, and FOGM. 


¢ ANSIC standard source code. 


¢ Broadcast networking to allow multiple simulations to operate together on dif- 
ferent IRIS workstations. 


A complete discussion of the user interface for APS can be found in Appendix C. 


2. APS Environment 

The vehicle control and motion model requires an interface with its simula- 
tor environment in four areas: maintenance of and access to terrain data structures; 
timing; control inputs; and display of results. From the terrain data structures, it 
needs the elevation of an arbitrary point in world coordinates. This is provided by the 
function gnd_level. It also requires the surface normals for each terrain polygon. Tim- 
ing is provided by the routines in module simtime (Appendix A). Control inputs are 
provided by reading the mouse position, reading dial positions, or receiving commands 
from a remote guidance system. Displaying the results, which after all is the main 
thrust of the simulation, is accomplished by drawterrain after the model "positions" 
the vehicle for drawing and sets up the viewing parameters and the projection trans- 


formation. 
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3. Graphics Drawing Cycle 
Typically, window-based graphics programs operate in a drawing cycle 
with an INPUT-UPDATE-DISPLAY loop. A representation for this cycle in the vehi- 
cle simulator is shown in Figure 4-2. The platform modeling routines operate in the 


update portion of this cycle. They operate on the platform data structure which 1s then 


wotEiabeze terrain, graphies, and I/0 
while ( state variable ) 
{ 
update Simulation timer 
while input in input queue 
{ 
read queued input device 
handle input 
} 


handle network input messages 


update guide points and controls (autopilot) 


update vehicle model 

update vehicle position 

draw objects 

send network update messages 





Figure 4-2 Structure of Main Drawing Loop in event_driving 


passed on to the display cycle. The only parameters usually required for model rou- 
tines are a pointer to the platform and the elapsed time since the last update cycle 


was completed. 


4. Input 
As discussed earlier, control inputs can have several sources, can be set 
to override each other, and can be turned on or off depending on the internal state of 
the simulator. The source of control inputs is largely irrelevant to the design of the 
motion model except for steering. Two ways of modeling steering correspond to two 


types of physical control systems. In one, the steering wheel or control device is 
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directly connected to the wheels, tracks or control surfaces of the vehicle (Figure 4- 
3). | External course commands then must be processed into signals to a 
servomechanism which physically moves the steering control just as a human 


operator would manipulate it. 


MANUAL 
CONTROL “x 


COURSE COMMAND CONTROL 


SERVO EFFECTOR 


Figure 4 - 3 Manual and Automatic Steering Control 





Another arrangement is "fly-by-wire" (Figure 4-4) where manual control 
generates a signal which is perhaps one of several input signals to a steering control 


system which in turn activates physical control surfaces such as wheels, tracks, or ai- 


CONTROL CONTROL GONGROU 


COURSE — > PROCESSOR EFFECTOR 
COMMANDS 





Figure 4-4 "Fly-by-Wire’’ Steering Control 


lerons. 

APS currently uses the first system. Course commands are converted in- 
to a turnrate. This turnrate is then used by model routines steering model and turn- 
Ing_model without caring if it came from the steering wheel or remote commands. 


Thus the modeling of turning is independent of the source of the turning commands. 
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5. Model Update 
The update phase (Figure 4-5) is actually split into two sub-phases. In 


a 


the first phase, the new velocity and course are calculated. In addition, any transient 


pitch or roll caused by a change in velocity 1s calculated. 


COMMAND COURSE 


COURSE 
VELOCITY: 


TRANS PITCH 
TRANS ROLL 





Figure 4-5 Vehicle Model Update Phase 


Once the model has updated the platform data structure, it 1s passed on to 
the routine update_veh_pos which "moves" the platform to its new location and calcu- 
lates orientation angles based on the slope of the terrain. Any oscillations or 
“bounce” in vehicle transient pitch angle is calculated by handle_bounce. This is 
based on the change in vehicle base pitch angle exceeding some threshold or mini- 
mum change. At this point, an interplay exists between attempting to smooth abrupt 
pitch changes between adjoining terrain patches and simulating bounce. Because the 
terrain is represented by patches, the flat tops of hills or mdges that are less wide 
than the terrain cell size are "missed" by the data base. Consequently cresting a hill 
and going down the other side is portrayed as an instantaneous change from positive 
to negative slope as the line separating the two adjoining patches is crossed. To 
smooth out this sharp transition the length of the baseline to the front of the vehicle 
used to calculate base pitch was extended forward about 20 meters. This results in 
the pitch change being spread over smaller increments as the reference point moves 
down the far slope as the vehicle is coming up the near side. Unfortunately this 


smoothing can also "smooth" oscillations out of existence. Only experimentation 
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with the constants pltchbase_distance and bounce_threshold can produce a realistic 


compromise. 


6. Platform Position and Viewing Parameter Update 

APS updates the vehicle position and orientation variables whether or not 
the vehicle is currently selected as the viewing platform, the driven vehicle. In MPS 
the viewer’s position was not fixed with respect to the dnven vehicle coordinate sys- 
tem. It was a constant Y offset from the vehicle’s graphical center in world, not body 
coordinates. On fairly level terrain this works well, but as the vehicle pitches and 
rolls when travelling over rough or sloping terrain the viewpoint or eye position ap- 
pears to bounce around inside the vehicle. This movement is disorienting and in some 
cases may even result in viewing the terrain from underneath the terrain polygons. 
One solution to this problem is simply to not draw the driven vehicle. However, the 
viewer then looses the frame of reference the vehicle outline provides, especially 
when the view angle is not directly to the front. A more satisfactory solution is to de- 
fine the viewpoint as an offset from the vehicle origin in vehicle (body) coordinates 
and transform the viewpoint into the graphics (world) coordinates required to estab- 
lish the viewing perspective. Such a transformation also allows the viewpoint to be 
placed at an arbitrary point in the vehicle which could represent, the gunner’s sight, 
commander’s cupola, etc. Setting the viewing perspective is then done as shown in 


Figure 4-6 where eye_x, y, z is the sum of vehicle position coordinates and the view- 


perspective( fov, 1.0, 0.1, MAXLOOKDIST ); 
lookat( eye_x, eye_y, eye_z, 


local_px, local_py, local_pz, (Angle)(vlewroll*RTOD_X_10) ); 





Figure 4-6 Setting Projection Parameters 


ing point offset in transformed world coordinates. 
The IRIS graphics software also requires a viewing "target" (local_px, y, 


z), for the lookat perspective routine. The homogeneous transform again provides a 
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means for calculating this visual target since it 1s simply a constant displacement 
along the body X-axis of the viewer. This corrects simplifications in MPS that ne- 
glect cant or body roll in determining point of view. This precision becomes important 
when a weapon system is modeled because the point of view is also the point of aim. 
A one degree error in azimuth caused by cant corresponds to a 18 meter error at a 
range of 1000 meters. Therefore, the MPS routine update_look_pos was modified to 


use this procedure. 


7. Network Communications 

As described in Chapter III, communications among vehicle simulators is 
handled differently than communications with the AI agent. Messages among vehicle 
simulators, whether each is functioning as a peer or a remote human commander, are 
passed over the network using broadcast datagrams, while the vehicle simulator and 
the Al agent communicate using a stream. 

Communication routines are divided into two levels: the APS message lev- 
el and the network service level. These levels and the modules that contain level 


routines are: 


APS message level check_for_packets (receive) 
network (send) 

message-stream management network_IO 

network system services netstream_services 


broadcast_services 
a. Vehicle Simulator Communications 
(1) Imitalization. Two network sockets, a transmit socket and a 
receive socket, are initialized for each vehicle simulator. The receive socket is bound 
to an address containing the APS broadcast port number. This port number is 
arbitrary, but must be unique to avoid interference with other network services such 
as “mail” and “rwho” and must be the same for all vehicle simulators. In APS, the 


broadcast port number is a program constant (DEFAULT_BRDCAST_PORT in 
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network.h). An alternative method of assigning a port is by defining a "service" in the 
network system file "/etc/services". The system service getservbyname can then be 
used to determine the port number at run time. This method has the advantage of 
allowing changes in the port number without recompiling the program should the port 
assignment interfere with some other network application. However, each system 
running a vehicle simulator must have the same service definition for APS. Finally, 
each socket is set to BROADCAST mode, non-blocking I/O, and has its buffer size 
increased to RECV_BUFSIZE (currently 40K bytes). Since the most common 


broadcast message is an UPDATE packet with a size of 180 bytes, each vehicle 


simulator can normally receive = 220 packets before the buffer overflows. In 
communication tests, no such loss of message traffic has yet been observed. 

After the sockets are established, each vehicle simulator sends a 
polling message to synchronize itself with any other already running simulators. A 
response to this initialization message sets the initial 10 KM terrain box to that area 
already being viewed by a running simulator. 

(2) Sending Messages. Messages are sent as character strings 
divided into a header string that identifies the type of message and a varying length 
data string. The first character in the header string is a message token, a character 
that uniquely determines the message type. The rest of a message is the formatted 
output of a sprint command containing from one to thirteen fields. All messages are 
built and sent by routines in module network(). This routine is called with one 
argument indicating the type of message that is requested. Message types are 
shown in TABLE 1. The function network() also contains several local static variables 
which contain data used in building a message. For example, to send an UPDATE 


message the routine set_cntlmsg_platform(platform_polnter) is called to set the 
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vehicle then network(SEND_UPDATE_PACKET) is invoked to build and dispatch the 
message. 


TABLE 4-1 VEHICLE SIMULATOR MESSAGE TYPES 
TYPE FIELDS DESCRIPTION 


INIT_MESSAGE Polls for other vehicle simulators. 


ANS_MESSAGE x_grid, y_grid Answers INIT_MESSAGE and 
sets origin of L1OKM box. 


UPDATE_PACKET _ vehicle id, type, Updates platform data on remote 
UTM x,y, course, vehicle simulators. 
speed, weapon azimuth, 
weapon elevation, 
transient pitch, transient 
roll, control mode, 
external guidance. 


END_PACKET base 1d number Tells remote vehicle simulators to 
delete all platforms belonging to 
this host. 


FIRE_MESSAGE firer x,y,z, target x,y,z, | Sends a weapon system firing 
weapon azimuth, event. The flight of the projectile 
weapon elevation 1s then modeled on each 

simulator. 


LOCK_ON_MESSAGE vehicle id Sends id of platform that is/is not 
LOCK_OFF_MESSAGE being tracked by FOGM. 


DESTROY_MESSAGE vehicle id Sends message notifying remote 
CRASH_MESSAGE simulators that platform has been 
destroyed. 





(3) Receiving Messages. Since datagrams contain discrete APS 
messages, the type of an incoming message is determined by matching the first 
character of the header string with a character token. The data string is_ then 
disassembled by a formatted string read (sscanf in C) and the appropriate action taken. 


This message handling occurs in module check_for_packets(). Once during each 


61 


drawing loop this routine is called. It loops handling messages until no input is 
available. 
b. Vehicle Simulator - AI Agent Communications 

(1) Initialization. The communications stream is set up by initializ- 
ing a stream socket, setting it to non-blocking I/O, increasing its buffer size to 
RECV_BUFSIZE bytes, and establishing a connection queue by calling the listen 
system service. The socket is then polled once each drawing cycle using a non-block- 
ing accept system service. Two sockets are then cloned to handle the receive and 
transmit streams and a global flag, control_connected, is set indicating a connection 
with the AI agent has been established. 

(2) Sending Messages. Messages are sent as a continuous string 
of characters with no imbedded "white space" characters such as spaces, tabs, or 
linefeed. All numeric fields must be zero filled. Each message is preceded by a fixed 
number of a unique delimiter token characters, usually a punctuation character, {,?7,@, 
etc.. The variable length data string follows. A message is terminated by a number 
of delimiter characters, one less than at the front of the message. Since stream I/O 
implies an unbroken flow of data, these front and read delimiter characters serve to 
identify the type of message and provide begin and end message markers at the pro- 
gram level. This additional framing allows resynchronization should a portion of a 
message be lost or garbled. It also allow recognition of different type messages by a 


simple finite state machine. Messages to the AI agent are built and sent by calling 
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routine control_message(message type) contained in the module network. The types 
of messages sent to the AI agent are contained in Table 2: 


TABLE 4-2 VEHICLE SIMULATOR to AI AGENT MESSAGE TYPES 


TYPE FIELDS DESCRIPTION 


INITIALIZE UTM x,y of I1OKM box Tells AI agent which platform to 
origin, vehicle id, plan path for and what part of 
path start x,y goal x,y, _‘ terrain database to load. 
Simulation time 


vehicle id, vehicle Updates platform data. Initial 
location UTM x,y, guidance ON message triggers 
simulation time, path calculation. 

guidance flag 


OBSTACLE obstacle vertices Sends coordinates of vertices of 
detected obstacle. 


CONTROL vehicle id, Sends status and control flags. 
simulation time, 
control code 





(3) Receiving Messages. Routine check_for_packets() also 
handles incoming stream messages by calling recv_control_message(). If no AI agent 
is connected, it polls for a connection. If it can form a valid APS message from 
characters in an internal buffer, then it returns TRUE otherwise it returns FALSE. 
Messages are recognized using a finite state machine. Incoming characters are 
returned to recv_control_message() by get_msgchar(), which returns the next 
character in the block buffer and keeps the buffer filled as necessary by reading the 


Stream. If the stream read returns OQ, then the client has broken the connection so the 
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current message, if any, is discarded and the flag is set to begin polling for a 
reconnection. Message types received from the AI agent are contained in Table 4-3. 


TABLE 4-3 AI AGENT to VEHICLE SIMULATOR MESSAGE TYPES 


FIELDS DESCRIPTION 


vehicle id, If external guidance is set for plat- 

path point UTM x,y form matching vehicle id, then the 
platform’s guide point is replaced 
by the incoming point. If recv_path 


is set for platform then incoming 
point is added to path being built. 


CONTROL vehicle id, Turns guidance ON/OFF, 
simulation time, recv_path ON/OFF, or 
control code autopilot ON/OFF. 





8. Simulation Time 
It is often desirable to change the speed at which the simulation runs by 
modifying the ratio between real (clock) time and simulation time. This is done by fil- 
tering calls to the system clock through the simtime module. This allows, for example, 
simulation time to be suspended while menus are displayed. The routines available are 


shown in Figure 4-7. 


9. Simulating Weapon Systems 

Platforms in APS can be equipped with weapon systems by defining the 
weapon's characteristics, ammunition types, and sight reticle. A platform with a weap- 
on system can engage and destroy any other platform, local or remote. Figure 4-8 
shows the view through a TOW weapon sight looking at an attack helicopter. Weapon 
data structure definitions are contained in "weapons.h" which is reproduced in Appen- 
dix A. Current weapons include tank main gun with SABOT and HEAT rounds and the 
TOW antitank weapon system. 


start_slmtime() - Starts simulation tlme at 0. 


stop_simtlme() - Halts simulatlon tlme from advancing, 
l.e. freezes time. 


restart_simtime() - Restarts simtime when halted. 


change_simspeed( float ratlo ) - Changes the ratlo of 
simulation time / realtime. That Is, a ratlo value 
of 0.3 will cause simulation to run 3 times slower 
than real time, or 3 seconds of real time will elapse 
for every 1 second of simulation time. 


float read_simtimer() - Returns the current time since start_simtime 
was Called in simulation seconds. 


void set_time_mark( vold ) - sets a tIme mark by storing current value 
of simtimer In local static “package” varlable. 


float elapsed_time_wreset( vold ) - returns elapsed tlme In seconds 
since tIme mark and resets time mark. 





Figure 4 - 7 Simulation Timer Module Routines 
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Figure 4-8 View Through TOW Weapon Sight : 
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Weapon system data structures are as general purpose as possible, to fa- 
cilitate addition of other types of weapon systems and munitions. Each platform con- 
tains an array of pointers to onboard weapon systems, one of which is selected as the 
current weapon. Each weapon system is represented by an instance variable which 
contains data specific to that platform and pointers to class variables which contain 
generic data for that type of weapon or munition. The tank, for example, has a pointer 
to its weapon class variable and a pointer to the munition class variable for the partic- 
ular type of round currently selected. Which sight reticle is drawn is determined by 
looking into the weapon class variable of the currently selected weapon for the cur- 
rently selected platform. Presently tank main gun, binoculars, and TOW sight reticles 
are available’. 

Target ranging is also simulated for those weapons that normally have 
such a capability. The tank, for example, simulates a LASER range-finder by doing a 
gselect (similar to a graphic pick) on a three degree field-of-view along the firer’s 
line-of-sight (LOS). The select list is examined for platform identifiers, except that 
of the firer, and returns the range to the closest one. This range is displayed in the 
weapon sight reticle. Platforms which no weapon system, such as jeeps, of course 
have no range-finding capability. They have, however, been provided with variable 
power binoculars selectable from the main driving menu. 

Although range-finding with a LASER happens quickly enough so that it 
can be completed in a single iteration of the drawing loop, actions such as the flight of 
a round extend over multiple drawing cycles. In order to support such transient 
events without congesting every possible drawing loop in APS, an event handler 
which is called once each drawing loop was implemented. Events, such as a round in 
flight, are implemented as a linked list of event data structures (described in 
“weapons.h") with a common part containing a time stamp, delete flag, and pointer to 


" Data is unclassified hypothetical data representing the generic characteristics of the represented item and is not intended to 
exactly match any actual system. 
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a function which can process this type of event. Each event also contains a vanant 
part containing type-specific event data fields. Once each drawing loop the event 
handler is called. It traverses the event linked list. If an event is not marked for dele- 
tion, a call is made to its processing function via the pointer, with the address of the 
event record as the parameter. This allows the event processing function access to 
the type-specific data. Types of events currently implemented are: 

1) round_in_flight - flies ballistic trajectory. 

2) reset_safety - timeout to reset weapon safety after reload time. 

3) message - displays message on screen for set period of time. 

4) splash - draw splash of round miss for specified amount of time. 

5) flash - draw expanding flash at impact of round with platform. 

6) bounce - varies vehicle pitch based on elapsed time since going over 
bump in the terrain. 

Firing a weapon in APS results in the simulation of the projectile’s flight 
until impact with the ground, another platform, or maximum range is exceeded. The 
system assumes that the weapon system has some type of ballistic computer that 
will provide elevation to the weapon based on the range to the target, type of ammuni- 
tion, etc.. This allows the position of the round along its ballistic path to be computed 
from a table of offsets in the Y (UP) direction, called its ballistic table, by scaling the 
offset using the current range from the point the round was fired. This produces an or- 
dinate for the current range. A cylindrical viewing volume is then constructed along 
the LOS at the ttme the weapon was fired offset by the ordinate. LOS guided muni- 
tions such as the TOW are processed the same way, except that their ordinate is al- 
ways zero and the flight volume is based on the firing platform’s current LOS not the 
LOS at the time of firing. The near and far clipping planes are set to the starting and 
ending position of the round during the increment of time since the last update. This 
cylindrical volume is "swept" using gselect and the closest target to the firing vehicle 


is destroyed, if it is hit. If no target is in the volume, the round is checked for impact 
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with the ground and a splash drawing event is added to the event list. Finally, if the 
round flies beyond the edges of the terrain box, or exceeds its maximum range, it 1S 


terminated. 


10. Module Descriptions 
This section presents a brief description of the main modeling and simula- 
tion modules. 
a. Program Control Flow 
Program control flow is determined by state variables modified by the 
user through input from the dials, mouse, or menu system. Program structure 1s elab- 
orated in Appendix A and the user interface including the menu system in Appendix C. 
b. Supporting Routines 
Supporting routines that perform a single function are too numerous 
to fully describe here. A listing of all modules is contained in Appendix A. Due to the 
incremental development of MPS, some modules overlap in function. 
c. Data Structures 
The data used to model vehicle motion is kept in the platform data 
Structure defined in the "aps.h" (Appendix A). The platform data structure contains 
several state variables and toggles which are implemented as C enumerated types or 
a locally defined Boolean type. These state variables could be combined into a single 
variable using bit fields which would be more space efficient. This was not done due 
to the additional complexity of accessing bit fields and because bit fields are perhaps 
the least portable feature in ANSI C. 
d. Turning/Steering Module 
Steering is modeled using three routines: 


¢ float convert_course_to_turnrate( Vehicle ‘platform ) - Converts command 
course to turnrate which can be fed to the turning model. If the platform 
viewing mode is driver, the input is coming from the dials or the autopilot. 
This input is in the form of a commanded course or azimuth and the turnrate 
to direct the vehicle onto this course must be computed. This computed 
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turnrate is stored in the cmd_turnrate field of the platform record. This 
routine is implemented using the following rules: 


1) If the difference between the command course and current course is 
less than a small delta, CSE_WANDER, then make them the same. 


2) If the difference is less than AUTO_TURNRATE, then use difference 
as turnrate. Note that this may cause oversteer if the update time in- 
terval is greater than one second. 


3) Otherwise use AUTO_TURNRATE. 


* update_platform_steering model( Vehicle “platform, float elapsedsec, 

Boolean *network_packet_needed ) - This 
routine first calls turning model to calculate the current turnrate. It then ap- 
plies the current turnrate and time interval to calculate a new course. Final- 
ly, the viewing angles in the platform record are adjusted so that the view 
azimuth changes with the course. 


¢ float turning _model( float elapsedsec, 
float curr_turnrate, 
float cmd_turnrate ) - Returns exponential steering re- 
sponse if command turnrate is greater than current tumrate. If straightening 
out then centrifugal force is assisting so turnrate change is immediate. 


e. Velocity Module 
Consists of the routine float velocity_model( float dt, float slope, 
float currvel, float cmdvel, float *pitch, Boolean *network_packet_needed ). This rou- 
tine returns the new platform speed using methods described in Chapter III. It also 
calculates and updates the transient vehicle pitch due to acceleration or braking. This 
transient pitch simulates the torque on the vehicle body during sudden velocity 
change as the vehicle body is constrained by the suspension system. 
f. Bounce Module 
Vehicle bounce due to changing terrain slope is started by routine 
update_veh_pos which sets the initial transient pitch angle amplitude if there is a 
change in vehicle pitch greater than BOUNCE_THRESHOLD (currently two degrees). 
Routine handle_bounce calculates a new transient pitch angle and updates the bounce 
amplitude field in the vehicle record. If the bounce amplitude has fallen below 


PITCH_STEADY then it 1s set equal to zero. 
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g. Math Module 
Contains various general purpose math routines. 
float convert_normal_to_slope(float normal[3]) - Returns the slope angle of 
a terrain polygon in radians based on surface normal. 


transform_body_to_world( float azimuth, elevation, roll, 

float dx, dy, dz, 

float *eye_x, *eye_y, “eye _z)- Transform body 
coordinates to world coordinates. 
float calc_azimuth( float x1, float y1, float 21, float x2, float y2, float z2 ) - 
Returns azimuth in radians from the positive X axis for a course from point] 
to point2. 


h. Path Operations Menu Module 


This module (contained in do_pathops.c) contains the high level func- 


tions to create and delete a path, assign a platform to a path, and toggle the display of 


paths on and off. When called by selecting the "PATH OPERATIONS" option from 


the main driving menu, in module do_driving_ menu, a popup menu is constructed and 


displayed. If a valid menu choice is made then the function selected is performed by 


calling one of the routines: 


bulld_path - Displays instructions, initializes a path structure, adds a point 
to the path and redraws the new path each time the left mouse button is 
pressed, prompts for a path name when mght mouse button is pressed, adds 
path to path list, and updates path data file to add new path. 


select_and_remove_path - Displays instructions, when mght mouse is 
pressed uses pick to determine which path was selected, deletes path from 
path list, saves remaining paths in path data file. 


assign_veh_to_path - Displays instructions, when right mouse is pressed 
uses pick to determine which vehicle icon was selected, makes cursor into 
vehicle icon, when icon cursor is moved over any point on a path and right 
mouse is pressed uses pick to determine which path is selected, makes copy 
of path for platform and sets platform’s guide point to first point on the path. 
If platform is not local sends path over network to home simulator. 


This module also contains functions to pick and display paths: 


e 


draw_path - Draws a single path as a black line with a blue box around the 
first point and a red circle around the goal. Paths are drawn in overlay bit 
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planes so that it would not be necessary to redraw the entire 2D map each 
time a point 1s added to a path. 


display_paths - Displays all paths in normal drawing or pick mode depend- 
ing upon its argument and returns the path identifier of the picked path. 


pick_path - Calls display_paths in pick mode and returns pointer to the path 
selected or NULL if no valid path 1s selected. 


LC Path Module 


This module (contained in "path.c") is a package which contains the 


low-level functions that operate on paths. The path data structure was shown in Fig- 


ure 3-7. Paths are only manipulated using the functions in this module. Function pro- 


totypes are declared in "pathfunc.h". Since most of these functions operate on a 


specific path, most have a pointer to a PATH structure as one of the input arguments. 


Path points are kept as UTM coordinates and are converted to graphic system world 


coordinates as necessary. The following functions are supported: 


e 


e 


addpt - Adds a path point to the end of an existing path. 
addpath - Adds a path to the end of the path linked list. 


at_goal - Returns TRUE if path point has the same coordinates as the last 
point on a path. 


copypath - Copies path points from one path to another. 
delete_path - Deletes path structure and frees up space. 
delete_list_path - Deletes path from path list. 
delete_veh_path- Deletes platform copy of path. 

init_path - Returns pointer to a new path structure. 
load_paths - Loads paths from data file. 

nextpt_on_path - Returns pointer to the next point on a path. 


reset_platform_path - Clears platform path and reloads path originally as- 
signed if any. Calls start_down_path to set initial guide point to path point 
nearest platform’s current location. 


save_paths - Writes out all currently defined paths to binary file in the cur- 
rent default directory. The file structure description is contained in 
“pathdata.h". 


set_guidept - Replaces the platform’s current guide point with input argu- 
ments and discards remaining path points. 


UZ 


¢ start_down_path - Returns pointer to path point closest to the input argu- 
ment point (usually platform’s current location). 


¢ update_guidept - If platform is within VICINITY meters of current guide 
point and that guide point has a successor, set the platform’s guidept field to 
point to next point on the path. 


iy: Autopilot Module 
The autopilot works by setting the platform’s commanded course and 
speed to follow its assigned path. For each local platform that has its control field set 
to AUTOPILOT and has a non-NULL guldept (i.e., it has a point to head towards) 
the autopilot performs the following functions: 

1) Update the guide point if within a prescribed distance. 

2) Handles obstacles (currently not implemented). 

3) Update the platform’s emdese to the azimuth from the platform’s current lo- 
cation to its current guide point. 

4) Sets commanded speed depending upon the current distance to the guide 
point. If the platform is so close that it might overshoot the guide point then braking 
is applied by setting cmdvel = -1.0. The platform’s course is also frozen to avoid 
turning if the autopilot is engaged while the platform is near a guide point. Note that 
the current implementation does not control the platform with sufficient precision to 


navigate an obstacle field. 


B. RULE-BASED PATH PLANNER 

The path planner is implemented as three distinct levels. The top level is re- 
ferred to as the path planner control program. It is through this program that overall 
control of the path planner is accomplished. The intermediate level consists of the 
search control program, which is implemented on a separate Symbolics workstation. 
The search control program controls access to the implemented search algorithm. Fi- 
nally, at the lowest level is the implemented search algorithm. It is located on the 


same Symbolics workstation as its control program. 
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1. Path Planner Control Program 
The path planner control program is located on the Symbolics workstation, 
SYM4. It is implemented using ART, a rule-based, expert system shell. The rules in 
this program control the action of all subordinate processes. There are 24 rules, 
grouped into the following seven categories. 


e Set up 

¢ Communications 

¢ Clock actions 

¢ Vehicle monitoring 

¢ Vehicle and Path control 
¢ Search control 


¢ Fact clean up 


This grouping of rules is used for conveyance of explanation, and does not 
necessarily have any bearing on the firing order of the rules. Appendix B contains a 
listing of the code. 

a. Set Up Rules 

The location of the vehicle simulation program and the search are 
variable as stated in Chapter III. This requires that the user input the location of 
these processes at the start up of the path planner control program. Two menu rules, 
menul and menu2, are used for this. These in turn enable two communications start 
up rules, Start-iris-comm-links and start-sym-comm-links, These communications 
rules open a TCP/IP I/O stream to the vehicle simulator process on the appropriate 
IRIS workstation, and a CHAOSNET I/O stream to the search control program on the 
appropriate Symbolics workstation. Program start up is the only time any of these set 
up rules are fired. 

b. Communications Rules 

The heart of the path planner control program’s ability to monitor the 


actions of other processes on other machines is its ability to receive information. This 
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information is received via seven communications rules. Two of these rules, check- 
comm-links-iris and check-comm-links-sym are used to continuously check the I/O 
Streams for incoming messages. These are the only communications rules in the path 
planner control program that are cyclic in nature. These rules are at the lowest active 
precedence level, and therefore do not cause any problem with indefinite postpone- 
ment of other rules. The set up rules have a lower salience value but are only fired at 
program start up. These rules are cyclic because between the two of them they either 
assert facts that cause themselves to fire again, or cause rules to fire that in turn 
cause these two rules to fire again. These rules continue this cyclic action as long as 
there are no incoming messages. 

When an incoming message arrives, one of the two previously mentioned rules 
asserts a fact indicating the type of message that arrived. Once this fact is asserted, 
one of four message handling rules reads in the message from the appropniate I/O 
Stream and updates the knowledge base. These rules are: read-init-in, read-update- 
in, read-map-ready-in, and read-waypoint-in. The messages read in are as follows: 


¢ Vehicle initialization message 
¢ Vehicle update message 
¢ Search map ready message 


¢ Incoming waypoint message 


c. Clock Rules 
Each vehicle following a path computed by the path planner has a real 
time clock associated with it. The vehicle’s clock is initially set to the time contained 
on the initialization message. This is done via the set-clock rule. When subsequent 
Messages contain a time the vehicle’s clock is reset to the message’s time using the 
reset-clock rule. If no messages arrive over the networks the vehicle’s clock is 
updated via the update-clock rule. This last rule enables the path planner control 


program to calculate a projected new position for the vehicle. 


a 


d. Vehicle Monitoring Rules 
When a message arrives carrying vehicle update information, the up- 
date-vehicle rule modifies that vehicle’s schema to reflect the new location, course, 
velocity, time and guidance mode. If no message arrives to update the vehicle’s 
record, the update-clock rule gives the vehicle’s delta-time fact a value. If the value 
of the vehicle’s delta-time fact is positive, the change-position rule calculates the 
distance traveled, updates the vehicle’s location, resets the vehicle’s delta-time fact 
to 0, and indicates to the knowledge base that the vehicle has moved. 
e. Vehicle and Waypoint Control Rules 
When either the update-vehicle rule or the change-position rule fire, 
the knowledge base is updated to indicate that the vehicle has moved. This change to 
the vehicle’s schema within the knowledge base fires the check-for-new-waypoint 
rule. This rule calculates the vehicle’s current distance to the vehicle’s current way- 
point. If the distance to this waypoint is less than 200 meters, the vehicle’s control 
schema is modified with the fact, (new-waypoint yes). When the knowledge data- 
base contains the control schema for a vehicle with the fact, (new-waypoint yes), the 
send-new-waypoint rule fires sending a new waypoint to the vehicle simulator. In 
this implementation, every other waypoint is skipped to mimic more closely the hu- 
man commander’s capability of skipping over 100 meter grid squares in his path plan- 
ning. 
np Search Control Rules 
After a vehicle has been initialized in the path planner control pro- 
gram’s knowledge base, the load-map rule is fired. This rule tells the search control 
program to load a 10 KM by 10 KM map, with the specified lower left hand corner’s 
UTM coordinates. After the map has been loaded and the search control program 
sends a message indicating that the search map is ready, the start-path rule fires. 
This rule gives the search control program the start point, goal point, and the vehi- 
cles 1D: 
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g.  FactClean Up Rules 

In order to prevent false firing of rules, used facts and schemas are 
cleaned out of the knowledge base whenever possible. The clean-up-iris-msg and 
clean-up-Ssym-msg rules clean up unclaimed waiting message facts. These facts are 
asserted by the check-comm-links-iris and the check-comm-links-sym rules when 
there is a message out of synchronization or spurious characters in the I/O stream. 
The clean-up-waypoints and clean-up-vehicle rules are fired when a vehicle goes 
out of guidance mode on the vehicle simulator. These rules remove all references to 
the vehicle from the path planner control program’s knowledge base. This ensures 


that the next time the vehicle requests a path, an old path is not given. 


2. Search Control Program 
The search control program can be run from any Symbolics workstation, ex- 
cept SYM4 where the path planner control program resides. The search control pro- 
gram directly monitors the search algorithm and keeps track of which vehicles have 
maps and paths. The search control program receives two types of messages from the 
path planner control program. The first message requests that a 10 KM by 10 KM 
search map be loaded into a map array. This message specifies the vehicle and the 
UTM from the lower left hand comer of the 10 KM by 10 KM area to be searched. The 
second message requests that an optimal path be found from the start to the goal. 
This message specifies the vehicle, the start point’s UTM, and the goal point’s UTM. 
The map-array is a 102 by 102 grid. The size of this array is chosen to allow a search 
map with a resolution of 100 meter squares to be loaded into the map-array, including 
a border of non-traversable cells, to bound the search algorithm. 
a. Loading the Map 
When a message is received that requests a map be loaded, the 
search control program checks to see if that map has ever been loaded before. This is 


accomplished by first converting the map UTM and vehicle ID information, contained 
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as Strings in the message, to LISP symbols and stored in veh-map and current-veh. 
The *maps* list is then checked to see if the newly generated map symbol is on the 
list. If the symbol is on the list, a message is sent to the path planner control 
program indicating that the map is loaded and ready to be searched. Alternatively the 
search control program builds a map-array with slope data from the data file used by 
the search algorithm. Finally, the symbol value of veh-map is then stored to the 
symbol value of the symbol stored in current-veh. The symbol value of current-veh is 
then added to the list *vehs*. 
b. Searching the Map 

After the map is loaded, the search control program receives a mes- 
Sage requesting a search be done for an optimal path. The message received contains 
the vehicle’s ID, the desired path’s start and goal points in UTM coordinates, as well 
as the map’s lower left hand corner UTM coordinates. The UTM coordinates are con- 
verted to coordinates used by the wavefront search algorithm. The wavefront search 
algorithm is called with the appropriate map-array selected from the *vehs* list. The 
retumed list of points is converted back to UTM coordinates. During this conversion a 
random number generator is used to move the waypoints around inside their 100 
meter by 100 meter grid. This is done to simulate the commander’s selection of a path 
from a low resolution map. Since the goal point may be a specific point, it is appended 
to the end of the list. Each waypoint is also tagged with the requesting vehicles ID 
and a sequence number. The sequence number is used by the path planner control pro- 
gram to keep track of waypoints. 

c. Returning Waypoints 

Waypoints are sent to the path planner control program one at a time 
for each path. This is accomplished through the send-waypoints function. The function 
is sent the list *wave-paths*, every time the search-controller function cycles 
through its do loop. This list, that is sent to the send-waypoints function, contains, as 


separate lists, the remaining waypoints for every vehicle that has requested a path. 
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Each list is stripped of the first element, and this element, a waypoint, is sent to the 
path planner control program. This cycling continues until all of the waypoints have 


been transmitted. 


D. SUMMARY 

This chapter contains the description of the implementation of APS. The most 
Salient modules and structures of the vehicle simulator are described with specific ex- 
planations of key code fragments and routines. The rules and control flow of the path 
planner is also described with a thumbnail sketch of each family of rules. This chapter 
explains how APS works while the following chapter describes the results of running 


the system. 
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V. SIMULATION RESULTS 


APS achieves a large part of its research goals. A platform, depicted with a fair 
degree of realism, can be guided along a path, which is calculated in real-time, to its 
goal. However, direct comparisons of human and machine path planning are not pos- 
sible due to a bottleneck in communications between the vehicle simulator and ma- 
chine path planner. Also, due to time constraints, some capabilities were not 


implemented. The most important shortfall is local obstacles and obstacle avoidance. 


A. VEHICLE SIMULATOR 

The vehicle simulator achieves all the design capabilities listed in Chapter IV. 
Most importantly, it is able to support navigation of a platform along a designated 
path, under various combinations of manual and autonomous control. The path can be 
designated by a remote human commander or an AI machine. The remote commander 
can also turn the platform’s autopilot and external guidance controls on and off, even 
while traversing a path under AI agent control. 

The network communications supports connected multiple vehicle simulators 
with real time interaction supporting command and control and combat "dogfighting" 
capabilities. Simultaneous control of multiple platforms by different sources was dem- 
onstrated allowing local control of some platforms while others are controlled remote- 
ly by the AI agent. 

The current vehicle simulator drawing cycle speed hovers near 4 frames a sec- 
ond. This speed produces jerky scene changes on the visual display and makes pre- 
cise vehicle control difficult. However, it remains sufficiently realistic to support 
navigation over calculated paths. Run-time analysis indicates that steady state per- 


formance is bound by graphics operations and not computational load’. 


Topu utilization was 50%-70% with the CPU waiting predominately for graphics calculations or drawing. 
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B. PATH PLANNER 

Two key research goals of the path planner were to provide an easily under- 
stood interface between the vehicle simulation and the path planning algorithm, and to 
provide the mechanism for easy integration of search algorithms at the control inter- 
face level. The AI path planning program developed for this thesis has been tested in 
real time. The path planner supports the major goals of this thesis. It provides a func- 
tional interface whereby different search strategies can be evaluated and tested 
against a human planner. The AI path planner provided optimal paths for the driver of 
the simulated vehicle, using a wavefront search algorithm. 

The path planner spends between one and one half to five minutes finding an op- 
timal path. After the path is found the path planner control program begins returning 
waypoints. The issuance of waypoints along the path is not sufficiently fast enough to 
compete with the human planner. This is mainly due to the fact that the human plan- 
ner issues an entire path to the vehicle at the beginning of the path, while the AI path 
planner is only allowed to issue one waypoint at a time. The AI path planner must ap- 
parently wait on buffered network communications. A “work around" exists to force 
the AI path planner to send the entire path as soon as the path is found. This howev- 
er, would remove the path planner’s ability to react to changes in the terrain as the 
vehicle travels along the path. 

A rule-based path planner control program, written in ART, controls the flow of 
path requests and the issuance of waypoints. More than one simulated vehicle can be 
guided along a path at the same time. The path planner control program allows multi- 
ple vehicles to be guided as long as each has a unique vehicle ID. 

The randomly generated offsets to the waypoints that are used to simulate a 
human path planner’s waypoint selection within a one hundred meter square grid do 
not adequately simulate the way a human path planner selects waypoints along a 
path. The human planner generally chooses a path that transitions smoothly from grid 


to grid, except where demanded by terrain. The use of random numbers to select the 
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position of waypoints within the designated one hundred meter squares causes these 
waypoints to be unnaturally placed along the path. This can cause the simulated 
vehicle to make sharp changes in direction for no apparent reason. 

The skipping of waypoints to provide a more reasonable next waypoint for the 
driver only appears natural in terrain that is typified by gradual changes in slope. 
Where the terrain changes slope frequently and drastically, the skipping of waypoints 
can cause the vehicle to traverse areas of extreme high cost. This occurs when the 
path planner has planned a route around a finger of a hill, but the waypoint avoiding 


the finger is skipped. 


C. COMBINED SYSTEM 

Obstacles, obstacle avoidance and local path planning were not implemented. 
Therefore, path transit time was purely a function of vehicle speed and an actual opti- 
mal path directly calculable from the global terrain data. 

Several trials were min over identical routes (2-7 KM long) under human and AI 
agent path planning. Human path planning is relatively quick and accurate when there 
is distinctive terrain such as steep hills and flat valleys; that is, when the best route 
is fairly obvious. When terrain is mixed and the trade-off between going straight over 
Steeper terrain or making a detour is more subtle, the visual decision becomes more 
difficult. 

Since there were no obstacles, most trials were run with the autopilot. The au- 
topilot always tries to maintain maximum speed, so a correctly calculated optimal 
path traversed on autopilot should result in a minimum transit time. Unfortunately, di- 
rect comparison between human and AI agent planned paths was not possible due to 
the inability of the Symbolics system to keep up with the vehicle simulator. Instead 
of the AI agent updating guide points when the vehicle was within 200 meters, so 
that there would be no break in speed, the vehicle would often reach a guide point and 


come to a stop before receiving the next guide point. When such a delaved guide 
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point was received, an additional time penalty was incurred as the vehicle simulator 
accelerated up to the maximum speed allowed by the terrain. As a result of this delay 
In receiving new guide points, transit times under the Symbolics AI agent control 
were 2-3 times longer than transit times for human planned paths. Consideration 
was given to working around this problem by having the AI agent send the entire path 
once calculated. However, this would eliminate the capability for the AI agent to dy- 
namically modify the path, based on obstacles or other detours, so this option was re- 


jected. 
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VI. SUMMARY AND CONCLUSIONS 


A. LIMITATIONS 


1. Vehicle Simulator 
The APS vehicle simulator is currently limited in the following ways: 


¢« Applies only to tactical vehicles travelling off-road. 

¢ Models single gear transmission vehicle for acceleration. 
¢ Operates in a Single terrain database. 

¢ Has simplified vehicle-terrain interaction model. 

¢ Simulates joystick driving controls with a mouse. 


There are some features of the vehicle simulator that don’t work correctly 
or fail to work under certain special circumstances. A list of such features, the nature 


of the fault and all other known bugs is contained in Appendix D. 


2 Path Planner 
The AI path planner is currently limited in the following ways: 


¢ The path planner does not take into account local obstacle avoidance. 
¢ A vehicle can be run on an AI generated path only once. 


¢ Only one Symbolics workstation is available to run the path planner control 
program written in ART. 


¢ The terrain slope data file must be preprocessed into the correct format. 

¢ The planned path is limited within a ten kilometer region. 
B. AREAS FOR FURTHER STUDY 

The most pressing need for further development is to remove the bottleneck at 

the AI agent end of the communications and to add obstacles and obstacle avoidance. 
Breaking the path planner’s message processing logjam would allow direct 
comparisons between the actual transit time of human and machine planned paths, a 
major goal of this research. Obstacles would add the global-local dimension to 


functional assignment trade-offs between human and machine planners, another 
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unexplored area. Other areas for further study lie in increased realism and added 
functionality for the vehicle simulator with multiple algorithms the focus for the path 


planner. 


3. Vehicle Simulator 
The most fruitful areas for further study of the vehicle simulator are simula- 
tor realism, graphics performance, local autonomous operations, and program struc- 
ture/software engineering issues. 
a. Program Structure / Software Engineering 

The vehicle Simulator program consists of =37,000 lines of source 
code in 238 files. About 7500 lines are pure drawing code, that is, polygons and fig- 
ures. The majonty of the source files contain a single function. This flat program 
structure in such a large program doesn’t provide the modularity or encapsulation nec- 
essary to manage the rapid modification and maintenance necessary in a system sub- 
ject to the constant flux of research. For example, to add a new platform type, say an 
Armored Personnel Carrier (APC), would necessitate modifying more than 20 files, 
even if its graphical object definition, material definitions, and vehicle characteristics 
were already available. A requirement to modify the platform modeling or control for 
this new vehicle type would entail even more extensive and treacherous changes. 

An Object Oriented Programming (OOP) Language would provide an 
order of magnitude simplification of the program structure and code. Encapsulation 
would limit the effects of code modifications reducing debugging and retesting of work- 
ing components ensure the containment of side effects. Inheritance would eliminate 
duplicating code that performs essentially the same thing but in slightly varying 
ways. For example, this would allow each platform to be an instantiation of a general 
class containing methods for control, modeling, and display. These methods would 


then operate on class and local data structures to provide the required function. 
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Since the vehicle simulator is written in C and currently C seems to 
have the most thorough and efficient interface to the SGI graphics library, a C based 
OOP language such as C++ or ObjectiveC would be appropriate candidates for such a 
conversion, with a low risk that performance penalties might eliminate its advantages. 

Another alternative is Ada. Encapsulation and inheritance can also 
be implemented through Ada "packages". In addition Ada is expressive enough to 
serve as a program design language (PDL) and is, after all, the DoD "standard" lan- 
guage. 

b. Realism 

Current research at NPS has produced some capabilities that could 
enhance realism without a large performance penalty. The realism of the 3D depiction 
of terrain can be improved by increasing the resolution of the terrain data. This 
shrinks the size of the near view terrain polygons making them seem more natural. In 
addition, the terrain display could be made more realistic by adding "features" such as 
roads, structures, lakes, and vegetation. Winn and Strong [WINN&89] have demon- 
strated a terrain drawing system that, utilizing IRIS hardware support, increases the 
terrain resolution, helps realism through better shading techniques and boosts perfor- 
mance. They also developed a real-time line-of-sight system that could be useful as 
a alternative or additional cost function for path planning. Adoption of a standard 
graphical object definition language such as Pixar’s Renderman or Object File Format 
(OFF), the language developed at NPS [MUNSON89] would create access to a 
large library of realistic images of platforms and other objects. 

Vehicle realism could be enhanced by including the following features: 


¢ Multiple gear transmissions. 

¢ Realistic slope effects. 

¢ Sound. 

¢ Different model constants by vehicle type. 

¢ Adding vehicle stability effects; i.e., turn over or crash. 
¢ Energy/Fuel consumption. 
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c. Increased Capability 

APS is currently limited to preprocessed terrain data for one 35 
square kilometer area of the world. Drummond and Nizolak [NIZOLK&8&9] in FOST 
modified the original MPS terrain representation system to accept standard format 
DTED files, available for many parts of the world. 

Additional path planning cost functions, such as exposure to enemy 
observation, energy or fuel consumption, tactical maneuver advantage, etc., could be 
used as alternate or combined figures of merit to evaluate the quality of the product of 
the path planner in differing environments. 

The trafficability model could be expanded from a simple function of 
slope magnitude to consider soil conditions, vehicle traction, and anisotropic slope ef- 
fects such as those contained in the vehicle-terrain interaction model of Ross 
[ROSS89]. 

The unimplemented simulated vision system, planned to provide in- 
put on local conditions to the obstacle avoidance system, was modeled after the laser 
terrain scanning system of the Adaptive Suspension Vehicle [BIHARI&89: pg 61]. 
There is an interesting interaction between the range and resolution of the vision sys- 
tem, the speed of the obstacle avoidance process and the maximum safe speed of the 
vehicle. Simply put, the vehicle cannot safely go faster than its sensing and naviga- 
tion system can react and respond. Were local obstacles and obstacle avoidance im- 
plemented, this simulator could be used to compare the overall performance of vision 
systems by varying the sensing system parameters: range, resolution, field-of-view, 
and speed; and then navigating real terrain. 

d. Performance 

Vehicle performance in terms of frames per second is of concern in the 
vehicle simulator only insofar as it effects realism. Other researchers at NPS have 
looked specifically at performance and found no magic algorithm that promises orders 


of magnitude improvement due to software changes [FICHTN&88]. That does not 
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mean that performance comparisons are unimportant or that efficiency can be ignored, 


simply that performance is not directly germane to this research. 


4. Path Planner 
Two key research goals of the path planner used in this thesis were first, 
to provide an easily understood interface between the vehicle simulation and the path 
planning algorithm, and to provide the mechanism whereby search algorithms could be 
easily interchanged at the control interface level. This implementation of the path 
planner is a prototype that needs to be refined and expanded. Areas of research that 
would provide significant improvements on this study are as follows: 


¢ Incremental route planning 
¢ Selection of route planning algorithms depending on requirements 
¢ Comparisons of expert system shells 


¢ Comparisons of search algorithms using real terrain data and simulated vehi- 
cles 


¢ Improved communications 


a. Search Algorithms 
The wavefront search algorithm used in this study 1s well understood 
and provides a standard by which other search algorithms can be judged. There are 
many other algorithms available that provide capabilities unique to each. The decision 
to use a particular search algorithm may be based on the constraints of the path and 
mission. An area for further study is to select appropriate search algorithms, depen- 
dent on the terrain and mission to be planned. Another area of study is the use of a 
preprocessing algorithm that would allow the vehicle to start along the path before 
the path is completed and still get reasonable results. 
b. Expert System Shells 
The path planner was implemented in ART which provides a high lev- 
el symbolic programming environment that allows predicate representation of rules. 


This representation allows the path planner written in ART to be understood by any- 


88 


one who has a grasp of predicate logic. ART however is not currently supported on 
the next generation of Symbolics workstations, nor is ART code easily converted to 
some common language and then transported to some other LISP machine. This last 
area of research is particularly interesting as graphics machines are beginning to in- 
corporate LISP processors as an integral part of the architecture. 
c. Communications 

The path planner has not been able to keep up with the vehicle simu- 
lation. There appears to be a problem with the buffering of messages in the Symbolics 
workstations. The path planner could also be improved by the addition of algorithms 
that would check for the most recent update message instead of filtering down 


through the messages that have arrived and backed up in the buffer. 


C. SUMMARY 

APS provides a testbed for the study of real-time path planning and control 
strategies and algorithms without the cost of building actual hardware. It serves as a 
bridge between the theoretical study of a simplified abstract problem to applied re- 
search producing concrete performance under realistic conditions. The conclusions of 
this study show the feasibility and advantages of such as system in settling perfor- 


mance debates with empirical results. 
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APPENDIX A. VEHICLE SIMULATOR MODULE DESCRIPTIONS 


A. DATA DESCRIPTIONS 

Data structure definitions and program constants are contained in C “header 
files" which normally have an "h" suffix. A list of all APS header files is contained in 
Table A-1. The main data structures used in APS are contained in “aps.h" (Figure A- 
1) and "“weapons.h" (Figure A-2). Global variable declarations are contained in 


"global.h" which is included at compile time in the APS main module "aps.c". 


B. MODULE ORGANIZATION AND PROGRAM CONTROL FLOW 

The top level APS function main() (Figure A-3) is contained in the file “aps.c”. 
This module initializes the system, runs the simulator by calling event(), and cleans 
up during program termination. Module event() (Figure A-4) initializes the 
simulator, displays introductory screens, gets a user selection of a 10 Kilometer area 
to work in, handles the main menu selections and calls either of the two main drawing 
loops: event_driving() (Figure A-5) or event_flying() (Figure A-6). If the user 
selects RETURN TO MAIN MENU from the driving menu or the platform he is 
operating is destroyed, control returns to event(), the 10 Kilometer 2D map is 
displayed, and the main menu is presented to renew the cycle. If the user selects 
EXIT THE PROGRAM from the driving menu control then the program is terminated 
by returning control through event() to main(). The remaining modules contain 
functions which are either sub-packages under one of the main routines or general 
support functions that are called to do some task from several places. These 
modules, the functions contained in each one, and a brief description of what they do 


are listed in Table A-2. 
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aps.h 
Cobra_data.h 
Cobra_inside_pt.h 
color_scheme.h 
controls.h 
event_status.h 
files.h 
flamedata.h 
global.h 
gundata.h 
jeepdata.h 
legend.h 
lightcons.h 
lightdefs.h 


macros.h 


Main_rotor_data.h 
math_utulity.h 
missiledata.h 


Mrotor_inside_pt.h 


network.h 


TABLE A-! APS HEADER FILES 


Main global data structures and constants. 
Cobra object data. 

Object data for Cobra inside view. 
Program RGB color array indexes. 
Constants for controls. 

Main loop state definitions 

System data file names 

Object data for wreck (buming jeep flames). 
Global variable declarations. 

Tank main gun object data. 

Jeep object data. 

Positioning constants for legend windows 
Material definition constants. 

Lighting array declarations. 


Copy of system header file that defines C 


macros without bug. 

Object data for Cobra main rotor. 
Math_utility function prototypes. 
FOGM object data. 


Object data for tip of main rotor seen from 
inside Cobra cockpit. 


Network message deluniters, types and 


formats. 


Sh 


TABLE A-1 APS HEADER FILES - CONTINUED 


network_services.h 


openjeepdata.h 
pathdata.h 
pathfunc.h 
popups.h 
rollerdata.h 
Rotdat.h 
Tail_pipe_data.h 
Taul_rotor_data.h 
tankdata.h 
terrain.h 
tiredata.h 
Tpipe_inside_pt.h 
trackdata.h 
trackdata2.h 
Trotor_inside_pt.h 
truckdata.h 
turitdata.h 
vehmodel.h 


weapons.h 


Network function prototypes. 
Open jeep object data. 

Path data structures definitions. 
Path function prototypes. 
Popup menu names and retum values. 
Tank roadwheel object data. 

Cobra rotor rotation rates. 

Cobra IR suppressor object data. 
Cobra tail rotor object data. 

Tank object data. 

Terrain 3D display constants. 
Wheeled vehicle ture object data. 
Cobra IR suppressor object data. 
Tank track object data. 

More tank track object data. 

Cobra tail rotor data. 

Truck object data. 

Tank turret object data. 

Platform motion modeling constants. 


Weapons system data structures and 


constants. 
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#include "gl.h" 

#include "fmclient.h" /* inherit font manager definitions */ 
#include "pathdata.h" 

/* pathdata.h required because there are ptrs to paths in Vehicle 


data structure. 


ye 
#ifndef NULL 


#define NULL 0 
#endif 


/* defines for manipulating the terrain data file */ 


#define ELEV MASK Om Leet 
#define RD 0 
#define WR 1 


Pewdefines for polygon computations */ 


#define X QO /* X coordinate */ 


#define Y 1 {/* X¥ af, 
#define Z 2 (pee Ys a7 
#define L 0 /* LOWER triangle */ 
#define U 1 pik UPPERS Griangile, ~/7 


Mmarcefines for polygon orientation */ 


#define MAXCOORDS 80 
#define MAXLOOKDISTF 6) ele ea (8) 


/* define maximum size for pickbuffer */ 


geeeeatie PICK BUFFER SIZE 512 


/* define default range for rangefinder */ 


#define RANGE DEFAULT 9999 
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/* defines for conversions */ 


#define 


#define 


0.447039 
0.3048 


TO MPS 
FEET TO METERS 


/* defines for useful constants ~~ 


#define 
#define 
#define 


#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 


#define 


#define 


ids */ 


#define 


#define 


#define 


TENTHKM 10020 

TWOTENTHKM ZO0OCRO 

HALF KM 500770 

ONEKM 1:0 002g 

TWOKM 2000720 

TENKM LOQ0 0G 

MAXLOOKDIST 5943.6 /* 5943.6 meters = 19500 feet */ 
MAXELEV 1134 /* 1134 meters = 3720 feet */ 
MINELEV 0 /* Q meters = 0 feet */ 
NUMXGRIDS 100 

NUMZGRIDS 100 

X DATA PTS en 

Z DATA PTS iB)! 

TANKGNDHT 16 Gaz 

TRUCKGNDHT 1.6764 

JEEPGNDHT Gee cilshiay 7! 

OPENJEEPGNDHT 0.6854 

TOWGNDHT ieee 

ATKHELHT Loe 

MAXVEH 999 


/* Maximum number of LOCAL platforms allowed */ 
MAXVEH NUMBITS 10 
/* Number of bits to shift host id to make room for MAXVEH 


VEHID MASK OxFFFFF 


/* Mask to get positive local base platform id */ 


MAXDEFAULTS 9 
FOGM_INIT_HT 50.0 
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/x defines for miscellaneous trig operations */ 


#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 


QTR PI 
HALFP I 
THREE QTR PI 
PI 

FIVE QTR PI 


THREE HALVES PI 


SEVEN QTR PI 
TWOPI 

RTOD 

RTOD X_10 
DTOR 


On 
she 


On & W W WN 


Gc 
a7, 
oe 
0: 


1Gaec oO LoS 
S10/96324 


- 35619449 
sl415 92654 
ezeo aU ik? 
ETE Fa 8). 6) 3h Sa 
-4977871 


263160307 
SOAS IES asl 
2.957750 
OP7 453292 


/*x* defines for cursor related stuff */ 


#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 


ARROW 
TANKCURSOR 
TRUCKCURSOR 
JEEPCURSOR 
FOGMCURSOR 
WRECKCURSOR 
OPENJEEPCURSOR 
COBRACURSOR 
CROSSHAIR 
XCURSOR 
BOXGURSOR 
BLANKCURSOR 
HRGLASSCURSOR 
STEERCURSOR 


faepiatform types */ 


#define 
#define 
#define 
#define 
#define 
#define 
#define 


NUMVEHTYPES 
TANK 

TRUCK 

Jee 

FOGM 

WRECK 
OPENJEEP 
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#define TOWVEH 
#define ATKHEL 


/* upper limit on weapon types per platform */ 
#define MAXWEAPONS 2 


#define MAX RDTYPES PER WEAPON 2 


/*x defines for the arrows drawn on the 2D terrain map */ 


#define ARROW LENGTH S050 
#define ARROW WING LENGTH OES, 
#define ARROW WING ANGLE 2550 


/* defines for window ids */ 
#define BILLBOARDWIN 
#define MAPWIN 
#define MENUWIN 
#define NAVWIN 
#define INDWIN 


m WW NYO FHF © 


/* Overdraw color defines */ 


#define CLEAROVERDRAW 
#define BLACKOVERDRAW 
#define REDOVERDRAW 

#define BLUEOVERDRAW 


COR 2G) 


/* defines for networking */ 


#define PACKED S=I2E Diez 
haath aa! Data type definitions RR Ree 
typedef float time £; /* time, §in floating polwees. - onc se. 


/* enumerated variable to indicate which viewing mode driven vehaawie 


aS in Fy 


typedef enum { normal view = 0, 
driver, 
binoculars, 
wpn sight } View modes ; 
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/* Define enumerated type for global variable to indicate current 
Elattorm control mode. 
a/ 
typedef enum { MANUAL = 0, 
AUTOPILOT )jmGont rol eeyper 


typedef enum { LOCAL = 0, NET } Vehowner; /* Origin of platform, 


local or network. */ 
typedef enum { OFF = 0, ON } Toggle; /* Indicates whether 
Semeeming 19 On or off. */ 


Pewtvpe definitions for platform data structure */ 


typedef struct vehicle { 


ae enet id; /* PLATFORM ID NUMBER FOR NETWORKING PURPOSES* / 
short puck id; /* PICK ID NUMBER FOR TARGETING PURPOSES */ 
Vehowner owner; /* indicates whether platform is local or net */ 
Beaeeol type control; /* Indicates how this platform is controlled.*/ 


View modes view mode; /* Indicates desired view from vehicle */ 
Roegele ext Qumdance;, /* Indi@ates whether external guidance 
PomonN Or OFF. i 
Toggle recv path; /* Indicates whether incoming guidepts 
sheuldsoe added onto existing path */ 
Boolean Sema, Update: /* Flag indicating whether update should 


be sent out over network for this 


platform. 
ae] 
short lee, /* PLATFORM TYPE */ 
Coord ey /* X TRANSLATION */ 
Goord ve /* Y TRANSLATION */ 
eeord Zz /* Z TRANSLATION */ 
gGouble utm x, 
utm_y; /* UTM Coordinates of platform to meter */ 

float cse; /* veh heading, (rotation about Y axis) 


fromepositigsesXeasi sym cadrans. Must 


be converted to compass degrees for I/O. */ 
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float 


float 
float 


float 


float 


float 


float 


float 
float 


float 
float 
float 
float 
float 
float 


cmdcse; 


turnrate; 


/* 


cmd turnrate; 


Baseepi tein, 


Crane. ple en, 


base roll; 


tahoe lay: 


Desired 


/* 


/* 


mf. 
/* 


af 
/* 


ay 
Vie 


ais 
/* 


* 


bounce amplitude; 


Dounce we ime, 


wpnaz; 
wpnelev; 
viewaz; 

viewelev; 
vel; 


cmdvel; 


/* 
j[* 
/* 
/* 
/* 
/* 
/* 


weapon system azimuth, 


( directed ) vehicle course */ 


psi dot - current turning ratem 
desired psi dot - either manually input 
through driving controlst or calculated 
when change of course received from 
remote controller. 
(tia let) due to 


veh pitch around Z axis, 


slope. 


transient vehicle pitch offset due to 


acceleration, vehicle bounce, etc. 


veh roll angle, around X axis (cant), due 


tovslope: 


transient vehicle roll induced by centrifugal 


force when turning. 


/* amplitude of platorm pitch oscillations 


/* 


accumulated time in seconds since bounce 


started. */ 


«7 


radians from X axis 


weapon system elevation from horizontal */ 


viewer’s angle of view from X axis in radians */ 


viewer’s elevation angle 


(Ea lie): -47 


VELOCITY IN METERS PER SECOND */ 


Platform control seer ing 


ue 


Represents the velocity commanded for the 


platform either by an outside controller or 


by setting the throttle control at a certain 


setting. 


A positive difference cmdvel - vel 


means acceleration and a negative difference 


means coasting to new lower velocity. 


A negative value for cmdvel is interpreted 
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as a braking faceom. range -1.0 <= v < 0.0. 


= 
float alt: /* ALTITUDE IF IT IS A FOG-M MISSLE */ 
Boolean track flag; /* IF TYPE IS A GROUND PLATFORM THEN */ 
/* FALSE = NOT BEING TRACKED * / 
es TRUE = IS BEING TRACKED 7 


/* IF TYPE IS A FOGM MISSILE THEN */ 
/* FALSE NOT CURRENTLY TRACKING */ 
his TRUE = IS TRACKING ay 
Struct vehicle *track; /* IF TYPE IS A GROUND PLATFORM THEN */ 
/* IT IS A POINTER TO THE FOGM, OTHERWISE */ 
/* IT POINTS TO THE GROUND PLATFORM */ 


/* WARNING: Following is ANSI C "incomplete structure definition" of 
structure contained in weapons.h. Such forward declarations MAY 


not be supported in non-ANSI C compilers. 


a / 
struct weapon_record *wpnptr[MAXWEAPONS]; /* AVAILABLE WEAPONS */ 
Bact weapon record *wpn selected; /* CURRENT WEAPON */ 


/* Fields containing pointer to associated path and the current 


guide point being used to navigate vehicle. 


ay 

PATH “Dae ae 

PTNODE AGuLaept ; 

struct vehicle *next; J" NEXT NODE IN THE WIStT */ 


} Vehicle 


Pee ype definition for fired weapon event */ 


typedef struct { 


rite Bal teisba sahil 

Coord Paved oe siired )y sia az 
Coord eat, wie Viet uae 

float wpnaz, wpnelev; 


} FIRE EVENTS; 


fm eeclare extern functions {alphabetical order ) */ 


extern float arcsine(); 
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extern float calc distance ( Coordezcl, secoord jy) Coord sz, 
Coord x2, Coord y2) Cocreuz wer 


xtern void center string map( chare*str, long linenumn ye 
extern void center string menu( char “str, leamo Pinenum |), 
extern float compass degrees to radvanvangle( tloammdeq a 
Gxt cri wee bel Sale convert atoudec wh: {) 7 

extern short convert to hr min(); 

exten jc amemr elapsed time _wreset (void); 

extern Vehicle *find (platform (nt aie mt. ce) mee |i 


check for packets.c */ 
extern float gnd level Coord 3, Geord 2); 
extern mousescreentoutm( short sx, short sy, 
double *utmx, double *utmy, 
short mousew) ; 
extern mouseutmtoscreen( double utmz, double utmy, 
short, 7S snorteagon. 
short window) ; 
extern mouseutmtoterrain( double utm~, double utmy, float *tx, float 
wh e75) 


extern mouseterraintoutm( float tx, float tz, double *utmx, double 


wie hei 05a) aa 

Cxrcern me Lede radian angle to compass degrees( ficat angles 

extern ete ime ne read Simeamer (>| 

extern float restrict angle to first revolution( float angteme 
/* wadians oniy ~~ 

extern float Ssincos( float angle, float *cosine ); 

extern Vehicle *switch veh() ; 

e-cern oa nere Cot num groundsver( 

€xtern, short tot num _veh(); 

extern double vecdotp (); 

extern double vecmag () 


/* declare very common global variables */ 
extern Vehicle *vehlist, *vehlistend, *driven; 
extern Boolean networking; 


extern int color scheme index; 


Figure A-1 APS.H Main Header File - Continued 


100 


extern int guidance signal; 


extern float eye position (NUMVEREYPES) (3); 

/* offset of eye from center of veh */ 
extern long centerx, centery; /* screen coord of center of MAPWIN */ 
extern Boolean control connected;/* flag indicating remote process is 


connected to server. 


yas 


Memeont handles - Initialized in initiris */ 
extern fmfonthandle Helv, HelvB, TimesRm, TimesRmB; 
extern fmfonthandle Scaled) timeskm, scaled Taimeskms, 
Scatedenely, sseated felvy; 

/*x* Make UTM coordinates of lower left corner of 10 KM box global */ 
extern double LL tenkmutm_x, LL_tenkmutm_y, 

UR_tenkmutm_x, UR_tenkmutm_y; 
/* Coord of Lower left of zoomed box */ 


extern double zoomed LL x, zoomed LL y; 
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[RRRRRKHEKRKKKKARKKKAKKRAKKKKKRKRKKAKK KKK AKKKKKKKKRAKKKKEKKRKR KARR KKK KKK KK 
’ 


NAME > weapons.h 

CALLED BY 

CALLS 

MODIFIED : 12/14/88 

PERSON : Bill Teter 

PURPOSE : Contains record and type definitions for weapons, 
ammunition types, and sight reticles for weapons systems. Uses some 


types from MPS.H so it must follow it in include statements. 


aa KA AKAKAKARAKARKAARKAKKKARKARKAKAKKKERAKKKARAKKKRAKREKKKKKKEKK / 


pee** Sight Types ****/ 
#define NORMAL 0 
#define M1TANK_MG 
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#define 
#define 


#define 
#define 
#define 


#define 
#define 
#define 
#define 
#define 


#define 


BINOS 2 


TOW 
DRAGON 
IFV_SBT 5 
IFV_HEI 
IFV_TOW q 


COBRA_TOW 8 
COBRA 20MM 9 
APACHE HF 10 
APACHE 25 11 


6..'0 


/* Reload time for generic tank system */ 


TANKFIRE INTERVAL 


/* Define FOV and ASPECT to set perspective when devecting fice. 


bi ckine me. 


#define 


#define 
#define 


#define 


#define 


typedef 
typedef 
typedef 
typedef 
typedef 
typedef 


ROUND FOV 3 
/*  .3 degrees or 6 mils */ 
ROUND ASPECT 0.8 
SPLASH DURATION 4.0 
/* How long to display target miss ground splash */ 
FIRING TBL INC 100.0 
/x Range increments in firing tables */ 
FIRING TBL LENGTH 10 
/* Number of entries in ballistic tables */; 


Struct worldcoordg2y a float x,Vv; } WCOGEDZ, 
Struct swor ldecordasp Float “,v,;Z;  }SWeOOrRDs, 
struct screencoord { short =;y7 jy CeoRnD, 


short Colorvectouns (>), 
long -Golorvecrorae =) 
tloae Cole pVececr an (i, 
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== Define record for class of ammunition or type of round == 


mc ce ce cs cs cm wc wc me me ee eee ee es es cc we ee es i es ee se 


| trajectory type ( ENUM ) | 


he rea + 
warhead ( ENUM ) 
$----------- ------ -- -- - - - - -- - - -- = - = = = = = = -- = ------ + 
| round mame {( STRING(10) } | 
$e eee + 
| speed ( meters/sec ) 
fa rrr + 
| minrange ( meters ) | 
hm nn nn + 
| maxrange ( meters ) | 
4+---------- -- - - - = 4+ 


/ 

typedef enum qdtype j{ BALLISTIC, GUIDED [LeSeamelxPE FLIGHT ; 

typedef enum ammo_type { INERT, CHEMICAL, NUKE, FASCAM, 
SUBMUNITION } TYPE WARHEAD ; 

mypedef struct munition type | 


iePE Pe bIGHT ELajeCeem aay pe, , SG DemorLetrayvectory * / 

TYPE WARHEAD warhead; /* type of warhead xf 

ehar round name([10]; Seeing name Of munition */ 

float speed; /* meters/second */ 

float minrange, /* minimum arming range */ 
maxrange; /* maximum effective range */ 

float Dateese le Cao weeny, 


} MUNITION CLASS;; 


Figure A-2 WEAPONS Header File - Continued 


1Q3 


| type | 
fr sn rn + 
| name — STRING l 
$a ee ern nnn + 
| magnification | 
fm rn nnn na + 
| numlines — # lines in reticle | 
fen nn == + 
| lines --> HAIRLINE (array) | 
pr ea + 
| Safenlighe | 
fon === = 
| range pesn )( pesmn ct rangems ering) | 
fo - = + 
| round posn ( posm ct wround s2ning.) | 
$---------- - - - = * 


a J 
typedef int CHAR POSN[2]; /* X,Y tuple defines origin Gfe - ae 
/* Lower left and upper right, dimensions of a rectangle */ 


typedef St pucl gress (2) perc, 


float Pe Cpe he a, eee ea 
} RECTANGLEZ2D; 
typedef struct hairline record { /* reticle nawriine Start 
Float Startiz)|, enad[2i-: 
} HAIRLINE; ; 


typedef Ssertver weetere cen am 


int type; /* code for type cf iretrecle \*/ 

char name[10]; /* string containing weapon/reticle name */ 
Snore Magnification; /* normal magnification ot sight 77 

ie numlines; /* count of number of hairlines in reticle */ 
HAIRLINE *lines; /* pointer to any array of HAIRLINE a 


RECTANGLE2D safe light; /* rectangle coordinates for safety light */ 
CHAR POSN range _posn; /* origin of range string */ 
CHAR_POSN round posn; /* origin cf round name Strime) */ 

} RETICLE; 
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mypedet struct RIF types { 


WCOORD 3 fire posn, /*e@ocationmof platform when 
round was fired. */ 
posn, /* location at last update */ 
pt of aim; jseMorldascoord ptreet aim */ 
float fired range, /* range data used when fired */ 
fired drst; /* current distance from pt where 
fired */ 
float angle, 
elev; 
Vehicle ne by ah ate / Spee eonplatform that fired 
the eround? / 
MUNITION CLASS * ammo; Pfoev ee Oreeound */ 
mee OUND IN FLIGHT;, 
/* ns ec ew we a se we we we ww we ww ws we ws ow ws a ae ae ae ee ee 
-- Define structure for class of weapon systems. There will be a 
a one of these records for each type of weapon system. aioe 
$-—--------------- - -- -- -- - - - -- -- - -- - -- - --- - - -- - -- - ----- + 
| Name wa sol RING | 
So rn + 
| sight --> RETICLE | 
+---------- 5 5 5 5 + 
| Geloodet Ie wet imes) | 
+---------------- --- - - = = - -- = $$ - $5 $5 $= = = - == + 
| amon types ms ( array Of e—-—> sMUNTITION CLASS ) | 
a en + 
| basie@uoad ( array Of int ) | 
a + 
a/ 
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typedef struct weapon type { 


char name [20]; /* name of weapon sys, ex: MlTank MG */ 
RETICLE *sight; /* sight picture used for this weapon type */ 
time f reload time; /* Minimum time between firings */ 


/* Array of pointers to posible munitions for this weapon sys */ 
MUNITION CLASS *ammo types[MAX RDTYPES PER WEAPON]; 
/* Brray holding starting quantities for avail munitions */ 


int basic load[MAX RDTYPES PER WEAPON]; 


} WEAPONS; 


DF a eS ee 
-- Define structure to represent weapon system carried by a a: 
==» —=S5s DPlatroum. a 
$------------ 5 “ 
| wong classi WEAEOGNS | 
+---------~--------------- -- -- -- -- --- --- -- -------------- “ 
| range ~eading | 
Se 
| Safety on ( refire FLAG ) | 
$+--------------- ----- - -- - - -- - -- -- -- - - -- - --- -- - -- ------- - 
| round select) ——] MUNI TIGig LAS. | 
+---------------------- --- -- - -- -- -- - -- - - -- = = = === + 
| Lasts f. ce Ci ascdmMen} | 
+---------~----~------------ ------- ----- -- -------------- + 
| rounds remaining arrayeby cyreeeoundss: | 
+------------------------------------------------------ + 
ay 
typedef struct weapon record { /* instance of weapon */ 
/* class variable */ 
WEAPONS *wpn_ class; /* ptr to weapon type record */ 
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/* instance variables */ 


float PAndemesaGins 6 / ecurrene reading in rangefinder an 

Ecolean safety on; /* flag whether weapon safety is on or off */ 
/* ptr to selected round, type of munition currently selected wai 
MUNITION CLASS peound select, 


/* time system was last fired, 0 if never fired. */ 

ame wt Vactme iene a. 

/* array of rounds of each type of munition remaining on platform */ 
eat rounds remaining[MAX RDTYPES PER WEAPON]; 


} WEAPON; 


— ote ete te Oe es es es es es ee es es ee ee ee ce ce es ce es ee ee es ee ee ee es es es ee es es oe es es es es es es es ew se es we es es i ee ee ee 


a ee ee ee + 
| delete ( FLAG ) | 
fe ran + 
Start time (atime) | 
+---—--------------- - -- -- - - +4 


| last Supdate si Seamer, | 


+-~---------~-~------~~~--------- --- - -------- ---------- + 
Proceespevenee = fiune(eo--event } | 
fm rrr + 
| hee event. “>> event 
+-------------------- -- —-- - -- - -- - - -- - - - - - - - - - = = + 
| variant ( UNION ) | 
a ee ee + 


/* Record for event variant part to reset something on a weapon after 
a certain amount of elapsed time. */ 


typedef struct weapon timeout { 


eame £ duration; 
WEAPON *wpnpt xr; 
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} WPN TIMEOUT; 


typeder struct ensgegc es. 


Zale 28 duration; 


char message [40]; 


} MESSAGE TYPE; 


typedef struct splash _ record { 


Goord aa aaa /* Where to draw round splash */ 


} SPLASH EVENT; 


typedef struct flash record { 


short CoOlernum: 


Vehicle ~“hitcvehnrve le; 


} FLASH EVENT; 


typedef struct { /* Record for vehicle “bounce! 


Vehicle =a-velce:. 


ELOat bounce amplituce; 


} BOUNCE EVENT; 


typedef union type sevens { 


ROUND IN FLIGHT EOUnG alert, 
WPN TIMEOUT wontimeout; 
MESSAGE TYPE letter; 
SPLASH EVENT splash; 


*/ 
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} EVEN 


typede 


} EVEN 


=—— De 


FLASH EVENT flash; 
BOUNCE EVENT bounce; 
/* add other timed event types here */ 


MeUNTON; 9 /* end union ~/ 
2. struct evielem re Cormd a| 
Boolean delete; /* Flag indicating expired event */ 
time f start_time, /* time event was initiated */ 
Vast uipdace, /* time when event was last 
updated */ 
int (GeEtececs Vent) (Struck event record *) ; 


/* pointer to function to handle this event */ 


meLuct event (record “next event, 


EVENT UNION Varlant yer artaAntepart Of record */ 
TS; /* end struct event record */ 
clare global variables to contain the values for actual a 


mmewEAPONS, RETICLE, and MUNITION CLASS classe ee 


extern 


extern 


extern 


extern 


WEAPONS ml tankmg sabot, 
ml tankmg heat, 
bitios elass, 


tow class; 
RETICLE NiGainkeguniner reticle, 
biniecmre:1cle, 
Gow ereel cle, 
MUNITION CLASS Mio salon, 
ml 10Sheat, 


tow standard; 


WEAPON binos; 


Figure A-2 WEAPONS Header File - Continued 
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INITIALIZE 


RUN 


TERMINATE 


euel 
ecode_arguements 
define_cursors 
inttiris 

setcolor_ initialize 
billboard 

light_ model 

init_ months 
makepopups 
load_paths 


event 


cleanup_on_exit 
exit_simulator 





Figure A-3 MAIN Module Program Flow 
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(Display Intro screens, 
display 35 KM map, & 
select 10KM area) 


display_big_map 
draw_box_around_current_area 
do_select_area 


(Initialize to 10KM terrain data base) 


read data 
calc_ground_ plane 
maketerrain 


initialize terrain mat 
terrainnormals 


(Display 10KM map & 
dispatch malin menu operations) 


display_legend_for_navbox 
display_map 
mapoverlay 
display_paths 


(Main menu options) 


eee ae 





Figure A-4 Module event() Control! Flow 
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control input loop 


handle network input 


update guide points and controls 


update vehicle model for each platform 


update vehicle position for each platform 


draw 3D view 


send network update messages 


set_queue 
setcontrols 
do_driving_menu 
setup_for_ driving 
handlecontrols 


check_for_packets 


autopilot 


update_veh_model 


update veh_pos 


viewbounds 
display_nav 
display_firebox 
display_indbox 
drawterrain 
display_data 
display_tracked_ data 


network 


Figure A-5 Display Loop in event_driving 
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control input loop 


handle network input 


check if FOGM tracking a target 


update vehicle position for each platform 


draw 3D view 


send network update messages 


set_queue 
setcontrols_fogm 
do_flying_menu 
handlecontrols_partial 
handlecontrol_fogms 


check_for_packets 


handle_tracking| 


update_veh_pos 
viewbounds 
update_look_ pos _fogm 


display_nav 
display_indbox_fogm 
drawterrain 
display_data 
display_slider 


network 


Figure A-6 Display Loop tn event_flying 


TABLE A-2 SUPPORT FUNCTIONS 


addflash.c 
addmessage.c 
addsplash.c 
addveh.c 
aps.c 
arcsine.c 


Hehe) 8) lel Ko} seme. 


bDisliiboardec 


Po virice sc 

broadcast Psexrvicesue 
galcueye (olLiseuae 

Gale ground =e lane ec 
Cale lock parameters 
calcwindows.c 

center cursor.c 

Genter strinegumarae 
Center String mentee 
Check Shor (packet s..c 


ehieck) round ened git le 


clearwindow.c 


cobra normals.c 
colli sionedetecta enc 


COMpure "Slope c 


compute start stop.c 


Adds round impact flash event to the 
event list 

Adds message display event to event 
list 

Adds round splash event to event list 
Adds platform 

Main routine 

Returns arcsine of input parameters 
Computes course and speed for 

plat form(s) 

Displays rotating billboard screen 
Computes oscillation due to terrain 
irregularities 

Contains low-level network routines 
for broadcast messages 

Calculates world position of viewer 
Place ground plane under terrain 
Calculates viewer position and view 
POIMe CL 2am 

Calculates windows sizes and stores 
in an array 

Positions cursor in the centerec ue. 
window 

Prints a centered string in the MAP 
window 

Prints a centered string in the MENU 
window 

Handles the reception and processing 
of network messages 

Updates round position, handles 
round impact with platform or ground 
Clears a window to input color 
Calculates normals for Cobra 
helicopter 

Detects collision between any two 
platforms 

Computes the slope of a line 


Computes information for drawterrain 
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TABLE A-2 SUPPORT FUNCTIONS - CONTINUED 


BPempute sun location.c Cemputes Sun (light source) location 


based on month and hour 


Sempute x bounds.c Computes x drawing limit for 
drawterrain 

Seomeute z bounds.c Computes z drawing limit for 
drawterrain 

Memvert to dec hr.c Converts toedecimal hour 

Senmvert to hr min.c Converts to hours and minutes 

Seeede arguments.c Handle command line arguments when 


aps in started 


feeime CuUrsors.c sets up cursor shapes 

Seeceec veh.c Deletes a platform and frees space 

@eeeplay big map.c Displays 35KM 2D map 

eeaplay data.c Displays CuEGenE system parameters 
Pom Soe 

Emoelay elapsed time.c Gem eres Lleating point seconds into 


HMS formatted string 
Sreeplay firebox.c Dasplays mouse legend for platform 
with weapon system active 
G@eteplay icon.c Displays all platform icons 
aeeplay indbox.c Displays mouse legend for platform 


without weapon system active 


Seeoplay indbox fogm.c Displays mouse legend for FOGM 
Pplacirorm 

eesplay Intro screen.c Displays program instructions 

Suaplay legend for big map.c Displays color gradation for 


elevation on 35KM map 
eaaplay legend for navbox.c Displays color gradations for slope- 


colored 2D 10KM map used for path 


planning 
display map.c Draws 10KM 2D map 
aasplay nav.c Draws blue course arrow and field-of- 


view limits 


faoplay slider.c Bruce ed oeeracking controls for FOGM 
plat form 

Baoplay tracked message.c Displays tracking message on the 
screen 


CS ee 
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TABLE A-2 SUPPORT FUNCTIONS - CONTINUED 


do capture.c 


do change speed <¢ 


doucharee 


do driving menu.c 


do tlving menue 


dominios 


do main.c 


Go Maine eser. c 


do pathops.c 


do wquit emg. 


do resize.c 


dowsetece area.c 


do the add.c 


dosthe derauies 7c 


do thevdelete jc 


dovthe selececc 


draw bomearound currene area.c 


draw cobra.c 


draw quidept.c 


Handles storing platforms into data 
file 

Allows user to set the speed of all 
pPlaetorms 

Displays a character in file name 
window 

Displays driving menu and handles 
selection 

Displays flying menu and handles 
selection 

Handles selection to display user 
Instruction window 

Builds and displays main menu and 
handles selection 

Clears all windows and displays 2D 
terrain map 

Builds and displays path operations 
menu and handles selections 

Handles program exit selection from 
any menu 

Handles resize selection from any 
menu 

Handles menu selection of a 10KM 
operational area on the 35KM map 
Handles menu selection of adding a 
platform 

Handles menu selection of adding a 
default set of platforms 

Handles menu selection of deleting 
one or all platforms 

Handles the selection of a platform 
Draws red box around current 10KM 
area on large map 

Draws the main body of the attack 
helicopter 

Draws a guide point as a marker on 


the terrain 
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TABLE A-2 SUPPORT FUNCTIONS - CONTINUED 


M@raw 1m cobra.c 


Seawemain rotor.c 


meameerojectile.c 
Beawereticle.c 
Grawecail pipe.c 
feawetail rotor.c 
drawflame.c 


drawflash.c 


drawgridbox.c 


Gmawgun.c 
@mawicon.c 


drawjeep.c 
drawmissile.c 
drawopenjeep.c 
drawroller.c 


drawsplash.c 


drawtank.c 


drawterrain.c 


drawtire.c 

drawtrack.c 
drawtruck.c 
drawturit.c 
drawwreck.c 


error handler.c 


event .Cc 
evenc driving.c 
eeent flying.c 


exit sgimulator.c 


Draws the cockpit framework when 
looking from inside the attack 
helicopter 

Draws attack helicopter main rotor 
blade 

Drawe round in ftlaght 

Draws weapon sight picture 

Draws attack helicopter IR suppressor 
Draws attack helicopter tail rotor 
Draws flame from tail of FOGM 
Draws flash when round impacts a 
plattorm 

Draws a box in the map window 
Draws the tank barrel and bore 

Se JaCcuarorn 

Draws the icon for each type of 
platform 

Draws the jee 

Draws the FOGM 

Draws the open jeep 

Draws) the tank rollers 

Draws the ground splash when a 
Drewece1 le impacts the ground 
Draws the body of the tank 

Main terrain and platform drawing 
routine 

Draws a tire 

Draws a tank track 

Draws the truck body 

Drawseene tank turret 

Draws a burning wreck 

Centralized error handler, just 
prints error message and returns 
Main drawing cycle dispatch routine 
Ground platform drawing cycle 

FOGM drawing cycle 


Cleans up on exit 
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TABLE A-2 SUPPORT FUNCTIONS - CONTINUED 


explosion.c 

tire blast se 

fire weapon.<¢ 
flamenormals.c 

gen wildman cde fauies ac 


Get .eurrce lps. ¢ 


get _ mouse xy.c 


Gero name-< 

gnd levelve 

gnd_ level luiM-c 
guidance.c 
gunnormals.c 
neand le werash ae 

handle Tevemts 7c 
handlevtraecung ee 
handléecontrots ec 
handleconUrolsntcumac 
handle COnGr ol Spare 1aiine 
ne gnlitegrrd rc 


iat comes. .c¢ 


at Momeliseie 


inat network c 


inte, Weapons. ¢ 


DMahG te eae eu ae Cuataciee mat.c 


Flashes screen when current platform 
is destroyed 

Flashes screen when weapon fires 
Handles weapon firing 

Computes normals for the FOGM flame 
Generates a default set of platforms 
Calculates current drawing rate in 
frames per second 

Gets current location of mouse cursor 
Opens window for user to enter file 
name 

Computes ground level of input world 
coordinates 

Computes ground level of input UTM 
coordinates 

Contains routines to handle 
transition between guidance states 
Computes normals for tank barrel 
Handles collision of two plattGrme 
Event handler package 

Handles FOGM tracking ground platform 
Handles mouse and dial inputs when 
driving a ground plattorm 

Handles dial inputs when flying the 
FOGM 

Handles mouse inputs when flying the 
FOGM 

Highlights the 1 X 1 KM grids “enat 
contain any platforms for zooming 
Initializes fonts and scales them to 
window size 

Initialize month and lighting 

Set up network sockets and stream 
server connection queue 

Initializes any weapon systems on 
bGardea plattorm 

Defines materials for terrain 


polygons based on current color map 
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TABLE A-2 SUPPORT FUNCTIONS - CONTINUED 


iar is.c 
initveh.c 
jeepnormals.c 
Petter. Cc 
Pigaeemode] initialize.c 
mrogntdefs.c 

Mimi cursor pick.c 
frat value.c 
loadunit.c 
makepopups.c 
maketank.c 


maketerrain.c 


maketrack.c 


mapoverlay.c 


Maem uUtility.c 


missilenormals.c 


Perce SCreentoutm.c 


mousescreentoworld.c 


mouseterraintoutm.c 


mouseutmtoscreen.c 


mouseutmtoterrain.c 


mouseworldtoscreen.c 


Metstream Services.c 


network.c 


Initializes graphics system 

Adds platforms from a file 

Computes normals for a jeep 

Draws a letter on the billboard 
Initializes lighting model and 
lighting viewer definition 

Defines materials, lights, and 
lighting model 

Limmismew. SOL Lor targeting attempt 
by FOGM 

Limits value between upper and lower 
bound 

beads sa unt Matrix onto the stack 
Builds static menus 

Builds polygon arrays for tank 
Fills the terrain elevation and 
terrain polygon normal arrays 
Makes tank track polygons 

Draws the platform icons on the 2D 
1O0KM map 

Package of math utility functions 
Calculates normals for the FOGM 
missile 

Converts sereen (piziel) coordinates 
to UTM coordinates 

Converts from screen coordinates to 
world graphics coordinates 

Converts from LOKM coordinates to 
UTM coordinates 

Comveres from UIM coordinates to 
point on the screen 

Converts from UTM coordinates to 
1O0KM coordinates 

Converts from 2D world coordinates 
to screen coordinates 

Package containing routines toa 
manage stream connections 


Builds messages and sends them 
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TABLE A-2 SUPPORT FUNCTIONS - CONTINUED 


NeGwork 10 7 
normalorient.c 

MpoO ly ret Pelee 
Obstacles ys 
openjeepnormals.c 
patiiv.c 

placewindow  sizes=c 


placewindows.c 


popwindow.c 


positionwindoywse 7. 


Pange “finde tre 


Bead data c 

EeSeCy ei. ere 
reticles.c 
tang tne be lin. 
rollernormals.c 
Selece onmane a. < 
Select egttd squace a. 
Select tate ..c 


Set dEtven View .c 


Set. popup celer ve 


set Gueuecec 


Package of message level network 
communication routines 

Computes normal and reorganizes 
vertices of pelygons 

Orients polygon vertices for 
backface method of hidden surface 
removal 

Stub module for obstacles package 
Computes normals for open jeep 
Package of routines to manage paths 
Sets aspect and size for billboard 
window 

Calculates the position ofeal 
windows and opens them 

Pops a window into full view 
Positions windows under window 
manager 

Simulates a laser rangefinder and 
calculates the range to nearest 
platform in weapon sight crosshairs 
Reads elevation and vegetation data 
from file 

Resets FOGM tilt angle after 
releasing tracking mode 

Variable definitions for sight 
reticle arrays 

Rings the terminal bell 

Computes normals for tank rollers 
Handles selection of an area on 35KM 
map 

Handles selection of 1 X 1 KM grid 
square 

Displays viewing mode menu and 
handles selection 

Sets viewing parameters for 
perspective and eye geometry 

Sets the color of the popup menus 


Queues up dials and mouse 


120 


TABLE A-2 SUPPORT FUNCTIONS - CONTINUED 


Beemungqueue.c 


setcolor.c 
Pemegtor initialize.c 
setcontrols.c 


Seeeantrols fogm.c 


Beeeursorcolor.c 


Beep for driving.c 
Setup navwin.c 
setwindow.c 
Beeworldcoord.c 
simtime.c 

SencoOs.c 


Pweech veh.c 


tanknormals.c 


@eerainnormals.c 


Eerenormals.c 


eeemaum ground veh.c 


eeennum veh.c 


eracking check.c 


tracknormals.c 
trucknormals.c 
@urivcenormals.c 


mecdate look pos.c 


Mpdate look pos fogm.c 


Mpaate veh pos.c 


vecdotp.c 


Unqueues dials and mouse 

Sets current RGB color based on 
values in RGB color array 
Mirtrali2zes RGbwecolor array 

SetseUp controls for driving 

Sets controls for Elying the FOGM 
missile 

Sets the current color of the cursor 
Sets up for driving using mouse 
7OvaGrek 

Draws small 2D 10KM map in 
navigation window 

Puts focus into a window 

Saves world coordinates of window 
Package containing routines to 
manage simulation time 

Returns interpolated table lookup 
values for sine and cosine functions 
Returns pointer to platform selected 
with mouse 

Computes normals for a tank 

Computes normals for the terrain and 
stores them in an array 

Computes normals for a tire 

Returns total number of ground 
platforms 

Returns total number of platforms 
Performs check of FOGM tracking 
system 

Computes normals for tank tracks 
Computes normals for truck 

Computes normals for tank turret 
Calculates position that viewer is 
lieetingedeater ground platform 
Calculates position that viewer is 
looking at for FOGM missile 

Moves platform to new position 


Computes vector dot product 
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TABLE A-2 SUPPORT FUNCTIONS - CONTINUED 


vecmag.c Computes magnitude of a vector 


vehmodel.c Package containing vehicle motion 
modeling routines 
viewbounds.c Computes viewing limits for 


drawterrain 





W222 


APPENDIX B PATH PLANNER CODE 


;3, -°- Mode: LISP; Package: USER; Syntax: Common-lisp -’- 

‘Title: clock functions 

‘Author: Shannon 

‘Date: 12 Apr 1989 

‘Discnption: This program provides for the timming of clocks used in the Path Planner Control Program 


(defflavor myclock ((start-ins-time 0) 
(start-sym-time 0) 
(last-ins-time 0) 
(last-sym-time 0) 
(delta-time 0) 
) 
() 


‘initable-instance-variabdles) 


(defmethod (:set-start-ume myclock) (iris-time) 
(let® () 
(sett last-iris-time iris-ume) 
(setf start-iris-time iris-time) 
(setf start-sym-tme (2I:time)) 
(setf last-sym-time start-sym-time) 
(sett delta-time 0) 
) 
) 


(defmethod ( reset-last-time myclock) (iris-time) 
(let® ((delta1 0.0) (delta2)) 
(progn 
(setf last-sym-time (ZI :time)) 
(setf last-iris-time iris-time) 
(setf delta1 (- iris-time start-iris-time)) 
(setf delta2 (- last-sym-time start-sym-time)) 
) 
) 
) 


(defmethod (:get-time myclock) () 
(+ delta-time (/ (+ 0.0 (time-difference (Z/:time) last-sym-time)) 60) last-iris-time) 


) 


(defmethod (:get-all-times myclock) () 
(pnnc start-iris-time) 

(princ start-sym-time) 

(pnric last-iris-time) 


(prince last-sym-time) -_> 
(prince delta-time) 


) 
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3, -°- Mode: LISP; Syntax: Common-lisp; Package: USER -*- 

‘Title: chaosflavor.lisp 

‘Author: Kwak 

‘Modified by: Shannon 

‘Date: 19 Apr 1989 

‘Discnption: This code performs the communications between Symbolics computers using a character stream. 


(load “comm-functions”) 


(defflavor mychaos ((host-name 'sym1) 
(contact-name “user-chaos’) 
(contact nil) 
(userstream nil) 
) 
() 


‘initable-instance-variables) 


(defmethod (:set-host-name mychaos) 
(name-of-host) 
(setf host-name name-of-host)) 


(defmethod (‘set-contact-name mychaos) (name) 
(setf contact-name name)) 


(defmethod (:set-contact mychaos) (con) 
(setf contact con)) 


(defmethod (:set-stream mychaos) (str) 
(setf userstream str)) 


(defmethod (‘start-user mychaos) (hostname contactname) 

(progn 
(send self :set-host-name hostname) 
(send self :set-contact-name contactname) 
(send self :set-contact (chaos:connect hostname contactname 13 72000)) 
(send self :set-stream (chaos:make-stream contact :direction :bidirectiona!)) 
(terpn) 
(pnnc “host name”) (princ host-name) 
(terpn) 
(pnne “contact name “) (pnnc contact-name) 
(terpn) 

“A conversation using chaos has been established”)) 


(defmethod (:start-server mychaos) (contactname) 
(progn 


IZ 


(send self :set-contact-name contactname) 
(send self :set-contact (chaos'listen contactname)) 
(chaos:accept contact) 
(send self :set-stream (chaos:make-stream contact :direction :bidirectional)) 
(terpn) 
(princ “host name ” ) (princ host-name) 
(terpri) 
(prince "contact name “) (prince contact-name) 
(terpn) 
"A conversation using chaos has been established”)) 


(defmethod (:put mychaos) 
(object) 


(send userstream ‘line-out object) 
(send userstream :force-output) 


) 


(defun read-string-sym (stream num-chars) 
(let ((out-string “")) 
(doumes (i num-chars) 
(setf out-string (string-append out-string (read-char-no-hang stream))) 
) 
out-sting 
) 
) 


(defmethod (:check-sym mychaos) (size-io) 
(let” ((typebuffer ) 
) 
(progn 
(setq typebuffer 
(read-string-sym userstream size-io)) 
) 
) 
) 


(defmethod (‘put-ready mychaos) 
(object) 
;From path-planner to art 
(let® ((buffer “!!!!")) 
(setf buffer (stting-append (string-append buffer object) *!!!")) 
(progn 
(send userstream ‘line-out buffer) 
(send userstream ‘force-output) 
't 
) 


(defmethod (:put-waypoint mychaos) 
(object) 
‘from path-planner to art 
(let" ((buffer "@@@@")) 
(setf buffer (string-append 
(string-append buffer (convert-number-to-string object)) 
"@@@’)) 
(progn 
(send userstream ‘line-out buffer) 
(send userstream ‘force-output) 
t 
))) 


(defmethod (:load-map mychaos) 
(utm-e utm-n veh-id) 
.From art to path planner 
(let® ((buffer *!!!")) 
(setf buffer (string-append 
(string-append buffer 
(convert-number-to-string (+ (" utm-e 1000000000000000) 

(" utm-n 10000000000) 
veh-id 
) 


get 


) 
(progn 
(send userstream ‘line-out buffer) 
(send userstream force-output) 
't 
))) 


(defmethod (:put-path mychaos) 
(org-utm-e org-utm-n start-utm-e start-utm-n goal-utm-e goal-utm-n veh-id) 
‘from art to path-planner 
(let* (buffer "@@@@") 
(string-org-e (convert-number-to-stnng org-utm-e)) 
(string-Org-n (convert-number-to-string org-utm-n)) 
(string-start-e (convert-number-to-string start-utm-e)) 
(string-start-n (convert-number-to-string start-utm-n)) 
(string-goal-e (convert-number-to-string goal-utm-e)) 
(string-goal-and-id (convert-number-to-string 


7 


(+ (° goal-utm-n 10000000000) 
veh-id 
) 


) 
(sett buffer (string-append 
(string-append 
(string-append 
(string-append 
(stting-append 
(stnng-append 
(string-append buffer 
string-org-e 
) 
string-org-n 
) 
string-start-e 
) 
string-start-n 
) 
string-goal-e 
) 
string-goal-and-id 
) 
"@@@" 
) 


(progn 
(send userstream ‘line-out buffer) 
(send userstream :force-output) 
it 
) 


(defmethod (:stop mychaos) 
() 


(send userstream :close :abort)) 
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:1; -"- Mode: LISP; Syntax: Common-lisp; Package: USER -*- 

‘Title: insflavor3 lisp 

‘Author: Kwak 

,Modification Author: Shannon 

‘Modification Date: 20 May 1989 

‘Discription: This code provides communications functions to the symbolics workstation, whereby it can 


communicate to the Ins 


(defmacro loopfor (var init test exp1 &optional exp2 exp3 exp4 exp5) 


‘(prog {) 

(setq ,var ,init) 

tag 
expt 
expe 
,exp3 
exp4 
exp5 
(setq ,var (1+ ,var)) 
(if (= ,var ,test) (return t) (go tag)))) 


(load “comm-functions’) 


(defvar *iris-port1” 1061) ; this is the send port 
(defvar “iris-port2” 1061) ; this is the receive port 
(defvar *local-talk-port® 1500) , this is the local send 
port 

(defvar *local-listen-port® 1501) ; this is the local 
receive port 


(defflavor conversation-with-ins ((talking-port-number = *ins-port1*) 
(listening-port-number °ins-port2’) 
(local-talk-port-number “‘local-talk-port’) 
(local-listen-port-number 

*local-listen-port’) 

(talking-stream) 
(listening-stream) 
(destination-host-object) 
) 

() 


‘initable-ins tance-vanables) 


(defmethod (:init-des tination-host conversation-with-ins) 
(name-of-host) 
(setf destination-host-object (net:parse-host name-of-host))) 
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(defmethod (:start-ins conversation-with-iris) () 
(setf talking-stream 
(tcp:open-tcp-stream destination-host-object 
talking-port-number 
local-talk-port-number)) 
(setf listening-stream 
(tcp:open-tcp-stream destination-host-object 
listening- port-number 
local-listen-port-number)) 
"A conversation with the ins machine has been established”) 


(defun read-string (stream num-chars) 
(let ((out-string *")) 
(dotimes (i num-chars) 
(setf out-string (string-append out-string (read-char-no-hang stream)))) 
Out-string)) 


(defmethod (:check-ins conversation-with-iris) (size-io) 
(let” ((typebufter) 
) 
(progn 
(setf typebuffer 
(read-stnng listening-stream size-io) 


) 


(defvar *step-var’ 0) 


(defun my-wnte-string(stning stream) 
(let” ((num-chars (length stnng))) 
(dotimes (i num-chars) 
(wnte-char (aref string i) stream) 
) 
) 
) 


(defmethod (:put-waypoint conversation-with-ins) 
(veh-id utm-e utm-n) 


(let* ((buffer (string-append 
Vi” 
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(String-append 
(convert-number-to-string veh-id) 
(string-append 

(string-append 
(convert-number-to-string utm-e) 
(string-append 

(stnng-append 
(convert-number-to-string utm-n) 
Wr 


(buffer-length (length buffer)) 


(lengthbuffer (convert-number-to-string buffer-iength)) 


(progn 
(my-wnte-string buffer talking-stream) 
(send talking-stream force-output) 
) 
) 
) 


(defmethod (:stop-iris conversation-with-iris) 
() 
(progn (send talking-stream ‘close) 
(send listening-stream ‘close))) 


on 


-:: -*- Mode: LISP; Syntax: Common-lisp; Package: USER -*- 

‘title comm functions 

‘author Kwak 

-discnption This program provides functions to the communications progarams that convert to and from strings 
and numbers. 


(defun convert-number-to-stnng (n) 
(pnnc-to-string n)) 


(defun convert-stning-to-integer (str &0ptional (radix 10)) 
(do ((j 0 (+j 1)) 
(n O (+ (° n radix) (digit-char-p (char str j) radix)))) 
((=j (length str)) n))) 


(defun find-period-index (str) 
(catch ‘exit 
(dotimes (x (length str) nil) 
(if (equal (char str x) (char *.” Q)) 
(throw ‘exit x))))) 


(defun get-leftside-of-real (str &optional (radix 10)) 
(do ((j 0 (1+})) 
(n O (+ (° n radix) (digit-char-p (char str j) radix)))) 
((Or (null (digit-char-p (char str j) radix)) (= j (length str))) n))) 


(defun get-nghtside-of-real (str &0ptional (radix 10)) 
(do ((index (1+ (find-period-index str)) (1+ index)) 
(factor 0.10 (° factor O 10)) 
(n 0.0 (+n (° factor (digit-char-p (char str index) radix))))) 
((= index (length str)) n ))) 


(defun convert-string-to-real (str &optional (radix 10)) 
(+ (float (get-leftside-of-real str radix)) (get-rightside-of-real str radix))) 


12 


v3, -"- Mode: LISP; Package: USER; Syntax: Common-lisp -*- 

, Tite define-packege-interface 

Author Shannon 

‘Date 24 May 1989 

;Discription Defines the interface between programs running in different Symbolics packages 


#L(defpackage cl-user 
(:export 

conversation-with-iris 
mychaos 
myclock 
convert-number-to-stnng 
convert-string-to-real 
convert-string-to-integer 
string-append 
princ-to-string)) 


Ils) 


33 %%% -*- Mode: ART; Syntax: Common-lisp; Base: 10.; Package: ART-USER -*- 

Tite: Path Planner Control Program 

author: Shannon 

;Date: 11 June 1989 

‘Discription: This program provides the over all control logic for finding a path and the sending that path to 
the vehicle simulation. 

#L(load “insflavor3”) 

#L(load “chaosflavor’) 

#L(load “def-interface”) 

#L(load “cdlockflavor’) 

#L(defvar talk-s) 

#L(defvar talk-i) 

#L(sett talk-i (scl:make-instance ‘user:conversation-with-ins)) 
#L(sett talk-s (scl:make-instance ‘user:mychaos)) 


(defschema counter 
(seq 0) 
) 


(defschema obsticle 
(instance-of counter) 
(nw-utm-e 000) 
(nw-utm-n O00) 
(sw-utm-e 000) 
(sw-utm-n 000) 
(se-utm-e O00) 
(se-utm-n O00) 

(ne-utm-e 000) 

(ne-utm-n O00) 

(seq 000) 

(seq-ord last) 

) 


(defschema obj-type 
(type unk) 
) 


(defschema location 
(utm-e 000) 
(utm-n 000) 

) 


(defschema id 


(veh-id 000) 
) 
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(defschema map-state 
(ready not-yet) 
) 


(defschema clock 
(clock-id new) 
(time 000) 
) 


(defschema control-conditions 
(new-goal no) 
(quit-all no) 
(broke-down no) 
(pause no) 
(whole-path no) 
(new-time no) 
(new-waypoint no) 
(old-time 0) 

) 


(defschema initial-map-points 
(org-utm-e O00) 
(org-utm-n 000) 
(start-utm-e 000) 
(start-utm-n 000) 
(goal-utm-e 000) 
(goal-utm-n 000) 

) 


(defschema control 
(instance-of clock) 
(instance-of obj-type) 
(instance-of id) 
(instance-of counter) 
(instance-of control-conditions) 


) 


(defschema map 
(instance-of obj-type) 
(instance-of location) 
(instance-of id) 
(instance-of map-state) 


) 
(defschema init 


(instance-of obj-type) 
(instance-of id) 


ee 


(instance-of inital-map-points) 
) 


(defschema veh 
(cse 0) 
(vel 0) 
(guide 0) 


) 


(defschema veh-change 
(delta-time 0) 
(new-position no) 


) 


(defschema msg-state 
(current no) 


) 


(defschema veh-state 
(instance-of obj-type) 
(instance-of veh) 
(instance-of id) 
(instance-of location) 
(instance-of veh-change) 


) 


(defschema veh-msg 
(instance-of clock) 
(instance-of obj-type) 
(instance-of veh) 
(instance-of id) 
(instance-of location) 
(instance-of msg-state) 


) 


(defschema machine-type 
(one one) 
(two two) 
(three three) 
(four four) 
(five five) 


) 


(defschema sym 
(instance-of machine-type) 
(one sym 1) 
(two sym2) 
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(three sym3) 
) 


(defschema ins 
(instance-of machine-type) 


(one gravy 1) 
(two gravy2) 
(three gravy3) 
(four gravy 4) 

(five gravy5) 

) 


(defrelation msg-sym (?type)) 
(defrelation msg-ins (?type)) 

(defrelation start-ins-comm (?t-or-f)) 
(defrelation start-sym-comm (?t-or-f)) 
(defrelation menu (?one-or-two)) 
(defrelation sym-on (?yes)) 

(defrelation check-comm (?ins-and-sym)) 
(defrelation clock-update (?yes)) 
(defrelation sym-link (?code)) 
(detrelation iris-link (?code)) 


(deffacts initialization 
(menu one) 


) 


(defrule menut 
(declare (salience -1000)) 
(schema sym 
(one ?s1) 
(two ?s2) 
(three ?s3) 
) 
?a <- (menu one) 
=> 
(pnntout t t "Where is the path planner located?") 
( 


printout t t "Your choices are the following, chose one by it’s letter. ° 


hey) 


t"a" ?s1 
t°b" ?s2 
fe + esa 
t "NOTE-—Please ensure that the path planning software is running” 
t) 
(bind ?b (read)) 
(if (or (eq ?b ‘a) 
(eq 7B ’A)) 
then 
(assert (sym-link 751) 
(menu two) 
(start-sym-comm yes) 
) 
else 
(if (or (eq ?b ‘b) 
(eq 2b 'B)) 
then 
(assert (sym-link ?s2) 
(menu two) 
(start-sym-comm yes) 
) 
else 
(if (or (eq ?b ‘c) 
(eq 7b ‘C)) 
then 
(assert (sym-link ?s3) 
(menu two) 
(start-sym-comm yes) 
) 
else 
(retract ?a) 
(assert (menu one)) 


) 


) 
(retract ?a) 


) 


(defrule menu2 

(declare (salience -1000)) 
(schema iris 

(One 711) 

(two 712) 

(three 713) 

(four ?i4) 

(five 215) 

) 
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?a <- (menu two) 
=> 
(printout t t "Where is the vehicle simulator located?") 
(pnntout t t "Your choices are the following, chose one by it's letter. * 
Ieee 711 
ab 7i2 
tee (713 
t°d* 214 
t"e * 715 
t "NOTE—Please ensure that the simulator is running” 
t) 
(bind ?b (read)) 
(if (or (eq 7b 'a) 
(eq 2b ’A)) 
then 
(assert (ins-link ?11)) 
(assert (start-ins-comm yes)) 
else 
(tf (or (eq 7b 'b) 
(eq 7b 'B)) 
then 
(assert (ins-link 712)) 
(assert (start-ins-comm yes)) 
else 
(if (or (eq 7b 'c) 
(eq 7b 'C)) 
then 
(assert (ins-link ?i3)) 
(assert (start-ins-comm yes)) 
else 
(if (or (eq ?b ‘d) 
(eq 7b 'D)) 
then 
(assert (iris-link ?i4)) 
(assert (Start-iris-comm yes)) 
else 
(if (or (eq 7b 'e) 
(eq 7b 'E)) 
then 
(assert (ins-link 715)) 
(assert (start-iris-comm yes)) 
else 
(retract ?a) 
(assert (menu two)) 


) 


WSS, 


) 


(retract ?a) 


) 


(defrule start-ins-comm-links 
(declare (salience -1000)) 
(iris-link ?ins-machine) 
2a <- (Start-ins-comm yes) 
=> 
#L(scl:send talk-i :init-destination-host ?ins-machine) 
#L(scl:send talk-i :start-iris) 
(retract ?a) 
(assert (check-comm ins) 


) 


(defrule start-sym-comm-links 
(declare (salience -1000)) 
(sym-link ?sym-machine) 
?a <- (Start-sym-comm yes) 
=> 
#L(scl:send talk-s ‘start-user ?sym-machine “path’) 
(retract ?a) 
(assert (sym-on yes) 


) 


(defrule check-comm-links-iris 
(declare (salience 500)) 
?a <- (check-comm ins) 
=> 
(bind ?b #L(scl:intern (scl:send talk-i :check-iris 1))) 
(if (eq 7b NIL) then 
(retract 7a) 
(assert 
(check-comm ins) 
(check-comm sym) 
(clock-update yes) 
) 
else 
(retract 7a) 
(assert (msg-ins ?b)) 


) 
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(defrule check-comm-links-sym 
(declare (salience 500)) 
(schema ?any 
(or (ready sent) 
(ready ready) 
) 
) 
2a <- (check-comm sym) 
=> 
(bind ?b #L(scl:intern (scl:send talk-s :check-sym 1))) 
(if (eq ?b NIL) then 
(retract ?a) 
(assert (check-comm iris)) 
else 
(retract ?a) 
(assert (msg-sym ?b)) 


) 


(detrule read-update-in 
(declare (salience 1000)) 
?msg <- (msg-ins 7a) 
(test(eq 2a '>)) 
=> 
(bind ?b #L(scl:intern (scl:send talk-i :check-iris 3))) 
(if (eq 2b '>>>) then 
(bind ?veh-id #L(scl:send talk-i :check-iris 10)) 
(bind ?utm-e #L(sci:send talk-i ‘check-ins 10)) 
(bind ?utm-n #L(scd:send talk-i :check-iris 10)) 
(bind ?cse #L(scl.send talk-i :check-ins 10)) 
(bind ?vel #L(scl:send talk-i :check-ins 10)) 
(bind ?time #L(sci:send talk-i ‘check-ins 10)) 
(bind ?guide #L(scl:send talk-i check-ins 1)) 
(bind 7b #L(scl:intern (scl:send talk-i :check-tris 3))) 
(if (eq 7b '>>>) then 
(bind ?msg-id "MSG") 
(bind ?msg-id #L(scl:intern (user:string-append ?msg-id ?veh-id))) 
(bind ?veh-id #L(user:convert-stnng-to-integer ?veh-id)) 
(bind ?utm-e #L(floor (User:convert-stnng-to-real ?utm-e))) 
(bind ?utm-n #L(floor (user:convert-string-to-real ?utm-n))) 
(bind ?cse #L(user:convert-stnng-to-real ?cse)) 
(bind ?vel #L(user:convert-string-to-real ?vel)) 
(bind *time #L(user:convert-string-to-real ?time)) 
(bind ?quide #L{user:convert-stnng-to-integer ?guide)) 
(modify (schema ?msg-id 
(veh-id ?veh-id) 
(utm-e ?utm-e) 
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(utm-n ?utm-n) 


(cse 7?cse) 
(vel ?vel) 
(time ?tme) 


(guide ?guide) 
(current yes) 


) 


) 

(retract ?msg) 

(assert (check-comm ins) 
(check-comm sym) 
(clock-update yes) 

) 


(defrule read-init-in 
(declare (salience 1000)) 
?msg <- (msg-ins ?a) 
(test (eq 2a ‘<)) 
=> 
(bind ?b #L(scl:intern (scl:send talk-i :check-iris 3))) 
(if (eq 7b ’<<<) then 
(bind ?org-utm-e #L(scl:send talk-i :check-iris 10)) 
(bind ?org-utm-n #L(scl:send talk-i :check-iris 10)) 
(bind ?veh-id #L(scl:send talk-i :check-iris 10)) 
(bind ?start-utm-e #L(scl:send talk-i :check-iris 10)) 
(bind ?start-utm-n #L(scl:send talk-i :check-ins 10)) 
(bind ?goal-utm-e #L(scl:send talk-i :check-ins 10)) 
(bind ?goal-utm-n #L(scl:send talk-i :check-ins 10)) 
(bind ?time #L(scl:send talk-i :check-iris 10)) 
(bind 7b #L(scl:intern (scl:send talk-i :check-ins 3))) 
(if (eq 7b '<<<) then 
(bind 7init “INIT") 
(bind 7init #L(scl:intern (user:string-append init ?veh-id))) 
(bind ?map “MAP*) 
(bind ?map #L(scl:intern (user:string-append ?map ?veh-id))) 
(bind ?cont "CONTROL") 
(bind ?cont #L(scl:intern (user:string-append ?cont ?veh-id))) 
(bind ?veh “VEH") 
(bind ?veh #L(scl:intern (user:sting-append ?veh ?veh-id))) 
(bind ?msg-id "MSG") 
(bind ?msg-id #L(scl:intern (user:string-append ?msg-id ?veh-id))) 
(bind ?org-utm-e #L(floor (User:convert-string-to-real ?org-utm-e))) 
(pnntout tt 7org-utm-e) 
(bind ?org-utm-n #L(floor (User:convert-string-to-real ?org-utm-n))) 


(pnntout tt 2org-utm-n) 


(bind ?veh-id #L(user:convert-string-to-integer ?veh-id)) 


(bind ?start-utm-e #L(floor (user:convert-string-to-real 
?start-utm-e))) 
(bind ?start-utm-n #L(floor (user:convert-string-to-real 
?start-utm-n))) 
(bind ?goal-utm-e #L(floor (user:convert-stnng-to-real 
?goal-utm-e))) 
(bind ?goal-utm-n #L(floor (user:convert-string-to-real 
?goal-utm-n))) 
(bind ?time #L(user:convert-string-to-real ?ume)) 
(bind ?clock-id #L(scl:make-instance ‘user:myclock)) 
#L(scl:send ?clock-id :set-start-time ?time) 
(assert (schema ?init 
(instance-of init) 
) 
(schema ?map 
(instance-of map) 
) 
(schema ?cont 
(instance-of control) 
) 
(schema ?veh 
(instance-of veh-state) 
) 
(schema ?msg-id 
(instance-of veh-msg) 
) 
) 
(modify (schema init 
(org-utm-e ?org-utm-e) 
(org-utm-n ?org-utm-n) 
(veh-id ?veh-id) 
(start-utm-e ?start-utm-e) 
(start-utm-n ?start-utm-n) 
(goal-utm-e ?goal-utm-e) 
(goal-utm-n ?goal-utm-n) 
(type init) 
) 
(schema ?map 
(veh-id  ?veh-id) 
(utm-e ?org-utm-e) 
(utm-n ?org-utm-n) 
(ready send) 
(type map) 
) 


(schema ?cont 


143 


(new-goa!l yes) 
(time ume) 
(old-time ?time) 
(veh-id ?veh-id) 
(clock-id ?clock-id) 
(type cont) 
(seq. 1) 
) 

(schema ?veh 
(veh-id § ?veh-id) 
(utm-e ?start-utm-e) 
(utm-n ?start-utm-n) 
(type veh) 
) 

(schema ?msg-id 
(type msg) 
(current no) 


) 


) 
(retract ?msqg) 
(assert 
(check-comm sym) 
(clock-update yes) 
) 


(defrule process-map-loaded-msg 
(declare (salience 1000)) 
?msg <- (msg-sym ?a) 
(test (eq 2a '!)) 
=> 
(bind ?b #L(scl:intern (scl:send talk-s ‘check-sym 3))) 
(if (eq 7b '!!!) then 
(bind ?cond #L{scl:intern (scl:send talk-s :check-sym 5))) 
(bind ?veh-id #L(scl:send talk-s :check-sym 10)) 
(bind ?b #L(scl:intern (scl:send talk-s :check-sym 3))) 
(if (and (eq 7b ‘!!!) 
(eq ?cond 'READY)) then 
(bind ?map "MAP") 
(bind ?map #L(scl:intern (user:string-append ?map ?veh-id))) 
(modify (schema ?map 
(ready ready) 
) 
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) 
(retract ?msg) 
(assert (check-comm iris)) 


) 


(defrule process-waypoint-in-msg 
(declare (salience 1000)) 
?msg <- (msg-sym 7a) 
(test (eq 2a '@)) 
=> 
(bind ?b #L(scl:intern (scl:send talk-s :check-sym 3))) 
(if (eq ?b '@@@) then 
(bind ?utm-e #L(scl:send talk-s :check-sym 5)) 
(bind ?utm-n #L(scl:send talk-s :check-sym 5)) 
(bind ?veh-id #L(scl:send talk-s :check-sym 10)) 
(bind ?seq #L(scl:send talk-s :check-sym 5)) 
(bind ?b #L(scl:intern (scl:send talk-s check-sym 3))) 
(if (eq 2b '‘@@@) then 
(bind ?way "“WAYPOINT") 
(bind ?way #L(sclintern (user:string-append 
(user:string-append ?way 
?veh-id 
) 
?seq 


) 

(bind ?utm-e #L(floor (user:convert-string-to-integer ?utm-e))) 
(bind ?utm-n #L(floor (user:convert-string-to-integer ?utm-n))) 
(bind ?veh-id #L(floor (user:convert-string-to-integer ?veh-id))) 
(bind ?seq #L(floor (user:convert-string-to-integer 7seq))) 
(assert (schema ?way 

(instance-of id) 

(instance-of counter) 

(instance-of obj-type) 

(instance-of location) 

(type w-point) 

(utm-e ?utm-e) 

(utm-n ?utm-n) 

(veh-id ?veh-id) 

(seq  ?seq) 

) 


) 
(if (0 = ?seq) then 
#L(scl:send talk-i :put-waypoint ?veh-id ?utm-e ?utm-n) 
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) 
(retract ?msg) 
(assert (check-comm ins)) 


) 


(defrule clean-up-waypoints 
(declare (salience 6000)) 
(schema ?way 
(type w-point) 
(veh-id ?veh-id) 
) 
(schema ?msg 
(type msg) 
(veh-id ?veh-id) 
(guide 0) 
(Current yes) 
) 
(schema ?veh 
(veh-id ?veh-id) 


(type veh) 
(guide 1) 
) 
=> 
(retract 
(schema ?way 


(instance-of id) 

(instance-of counter) 
(instance-of obj-type) 
(instance-of location) 


) 


(defrule clean-up-vehicle 

(declare (salience 5000)) 

(schema ?msg 
(type msg) 
(veh-id ?veh-id) 
(guide 0) 
(current yes) 
) 

(schema init 
(veh-id ?veh-id) 
(type init) 
) 

(schema ?map 
(veh-id  7veh-id) 
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(type = map) 
) 

(schema ?cont 
(veh-id ?veh-id) 
(type cont) 
) 


(schema ?veh 
(veh-id ?veh-id) 


(type veh) 
(guide 1) 
) 

=> 

(retract 


(schema init 
(instance-of init) 
) 

(schema ?map 
(instance-of map) 
) 

(schema ?cont 
(instance-of control) 
) 

(schema ?veh 
(instance-of veh-state) 


) 


(defrule clean-up-sym-msg 
(declare (salience 500)) 
?msg <- (msg-sym ?code) 
=> 
(retract ?msg) 
(assert 
(check-comm sym) 
(check-comm ins) 
(clock-update yes) 
) 
) 


(defrule clean-up-iris-msg 
(declare (salience 500)) 
?msg <- (msg-ins ?code) 
=> 
(retract ?msg) 
(assert 
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(check-comm iris) 
(check-comm sym) 
(clock-update yes) 
) 

) 


(defrule load-map 
(declare (salience 1000)) 
(sym-on yes) 
(schema ?map 
(utm-e ?org-e) 
(utm-n ?org-n) 
(veh-id ?veh-id) 
(ready send) 
(type map) 
) 
=> 
#L(scl:send talk-s ‘load-map ?org-e ?org-n ?veh-id) 
(modify 
(schema ?map 
(ready sent) 
) 
) 


(assert (check-comm sym)) 


) 


(defrule start-path 
(declare (salience 5000)) 
(schema ?veh 
(type veh) 
(guide 1) 
(veh-id ?veh-id) 
) 
(schema ?init 
(org-utm-e 7org-e) 
(Org-utm-n  ?org-n) 
(start-utm-e ?start-e) 
(start-utm-n ?start-n) 
(goal-utm-e ?goal-e) 
(goal-utm-n ?goal-n) 
(type init) 
(veh-id ?veh-id) 
) 
(schema ?map 
(veh-id ?veh-id) 
(type map) 
(ready ready) 
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) 


(schema ?control 
(new-goal yes) 
(veh-id ?veh-id) 
(type cont) 

) 

=> 

#L(scl:send talk-s :put-path ?org-e ?org-n ?start-e ?start-n ?goal-e ?goal-n 

veh-id) 

(modify 

(schema ?control 
(new-goal no) 


) 


(defrule send-new-way point 
(declare (salience 5000)) 
(schema ?any 
(type w-point) 
(veh-id ?veh-id) 
(seq ?seq) 
(utm-e ?east) 
(utm-n ?north) 
) 
(schema ?control 
(seq  ?seq-num) 
(veh-id ?veh-id) 
{type cont) 
(new-waypoint yes) 
) 
(test (and (?seq-num < ?seq) 
(?seq-num +3 > ?seq) 


) 


=> 
#L(scl:send talk-i :put-waypoint ?veh-id ?east ?north) 
(modify (schema ?control 


(seq ?seq) 
(new-way point no) 
) 


) 
(if (?seq-num = 1) then 
(assert (clock-update yes)) 


) 
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(defrule update-vehicie 
(declare (salience 1000)) 
(schema ?veh-msg 
(type msg) 
(veh-id ?veh-id) 
(utm-e ?utm-e) 
(utm-n ?utm-n) 
(cse ?cse) 
(vel ?vel) 
(time ?time) 
(guide ?guide) 
(current yes) 
) 
(schema ?control 
(type cont) 
(veh-id ?veh-id) 
) 
(schema ?veh-current 
(veh-id ?veh-id) 
(type veh) 
) 
=> 
(modify (schema ?control 
(time ?tme) 
(new-time yes) 
) 
(schema ?veh-current 
(utm-e ?utm-e) 
(utm-n ?utm-n) 
(cse ?cse) 
(vel ?vel) 
(guide ?guide) 
(new-position yes) 
) 
(schema ?veh-msg 
(current no) 


) 


(defrule update-clock 
(declare (salience 500)) 
?test <- (clock-update yes) 
(schema ?contro! 
(veh-id ?veh-id) 
(time ?time) 
(clock-id ?clock-id) 
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(type cont) 
) 


(schema ?veh 
(veh-id veh-id) 
(type veh) 
(delta-tme ?delta-time) 
(new-position no) 
) 
(test (?delta-time = 0)) 
=> 
(bind ?current-time #L(scl:send ?clock-id :get-tme)) 
(bind ?delta-time (?current-time - ?74me)) 
(modify (schema ?control 
(time ?current-tme) 
) 
(schema ?veh 
(delta-time ?delta-time) 
) 
) 


(retract ?test) 


) 


(defrule reset-clock 
(declare (salience 5000)) 
(schema ?control 
(time ?time) 
(old-tme old-time) 
(clock-id ?clock-id) 
(new-time yes) 
(type cont) 
) 


(schema ?veh 
(veh-id ?veh-id) 
(type veh) 
(delta-tme ?delta-time) 
(new-position ?no) 
) 
=> 
(if (eq ?no 'NO) then 
(bind ?delta-time (?tme - ?old-time)) 
) 
#L(scl:send ?clock-id :reset-last-tme ?tme) 
(modify (schema ?control 
(old-tme ?time) 
(new-time no) 
) 


(schema ?veh 


Si 


(delta-tme ?delta-time) 
(new-position no) 


) 


(defrule change-position 
(declare (salience 5000)) 
(schema ?veh 
(type veh) 
(utm-e ?utm-e) 
(utm-n ?utm-n) 
(cse ?cse) 
(vel ?vel) 
(delta-time ?delta-time) 
(new-position no) 
) 
(test (?7delta-time > 0)) 
=> 
(bind ?delta-dist (?vel ° ?delta-time)) 
(bind ?utm-e #L(floor (+ ?utm-e (° ?delta-dist (cos ?cse))))) 
(bind ?utm-n #L(floor (+ ?utm-n (° 7delta-dist (sin ?cse))))) 
(modify (schema ?veh 
(utm-e ?utm-e) 
(utm-n ?utm-n) 
(delta-tme 0) 
(new-position yes) 


) 


(defrule new-waypoint 

(declare (salience 1000)) 
(schema ?veh 

(type veh) 
(veh-id ?veh-id) 
(new-position yes) 
(utm-e ?utm-e) 
(utm-n ?utm-n) 


(guide 1) 
) 

(schema ?control 
(type cont) 
(seq ?seq) 
(veh-id ?veh-id) 
) 


(schema ?any 
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(type w-point) 
(veh-id ?veh-id) 
(seq ?seq) 
(utm-e ?east) 
(utm-n ?north) 
) 
=> 
(if (200 > #Lilet ((dx (- ?east ?utm-e)) 
(dy (- ?north ?utm-n)) 
) 
(sqrt (+ (° dx dx) (° dy dy))) 
) 


) 
then 


(modify 
(schema ?control 
(new-waypoint yes) 
) 
) 
) 


(modify (schema ?veh 
(new-position no) 


) 


ie 


-1; -*- Mode: LISP; Package: USER; Syntax: Common-lisp -*- 
, Tide: Search Control Program 

‘Author: Shannon 

‘Date: 5 Jun 1989 


‘Discnption: This program controls the flow of the search algonthm. 


( 

(setf “*done’® nil) 
(defvar *maps*) 
(setf “maps” nil) 
(defvar *vehs’*) 
(setf *vehs* nil) 
(defvar *°wave-paths*) 
(setf *wave-paths’ nil) 


(defun convert-to-utm (node-list map-utm-e map-utm-n) 
(let ((num-nodes (length node-list))) 
(dotimes (x num-nodes) 
(cond 
((eq x (- num-nodes 1)) 
(setf node-list (cdr node-list)) 
) 
(t 
(setf (car (car node-list)) (new-utm (car (car node-list)) map-utm-e)) 
(setf (car (cdr (car node-list))) (new-utm (car (cdr (car node-list))) 
map-utm-n)) 
(setf node-list (append (cdr node-list) (list (car node-list)))) 
) 
) 
) 
node-list 
) 
) 


(defun send-waypoints (wave-paths) 
(let ((num-waves (length wave-paths))) 
(dotimes (x num-waves) 

(terpn) 

(cond 
((null (car wave-paths)) 
(setf wave-paths (cdr wave-paths)) 
) 
((cdr (cdr (car wave-paths))) 
(send talk-s :put-waypoint 

(+ (° (car (cdr (cdr (car (car wave-paths))))) 
100000000000000000000 
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) 
(" (car (cdr (cdr (cdr (car (car wave-paths)))))) 
1000000000000000 
) 
(* (car (cdr (car (car wave-paths)))) 100000) 
(car (car (car wave-paths))) 
) 
) 
(setf wave-paths (append (cdr wave-paths) 
(list (cdr (car wave-paths))) 


) 


) 
(t 
(send talk-s ‘put-waypoint 
(+ (° (car (cdr (cdr (car (cdr (car wave-paths)))))) 
100000000000000000000 
) 
(* (car (cdr (cdr (cdr (car (cdr (car wave-paths))))))) 
1000000000000000 
) 
(* (car (cdr (car (cdr (car wave-paths))))) 100000) 
(car (car (cdr (car wave-paths)))) 
) 
) 
(setf wave-paths (cdr wave-paths)) 
) 
) 
) 
wave-paths 
) 
) 


(defun add-id (node-list veh-id) 
(let ((num-nodes (length node-list))) 
(dotimes (x num-nodes) 
(setf node-list (append (cdr node-list) 
(list (cons veh-id (car node-list))) 


) 


) 
node-list 


) 
) 


(defun add-seq-num (node-list) 
(let ((num-nodes (length node-list)) (seq 0)) 
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(dotmes (x num-nodes) 
(setf node-list (append (cdr node-list) 


(list (cons seq (car node-list))) 


) 
) 
(setf seq (+ seq 1)) 
) 
node-list 
) 
) 


(defun start-search-contol 
() 
(search-control) 


) 


(defun search-control 
() 
(load “Ir-wave’) 
(load “chaosflavor’) 
(setf talk-s (make-instance 'mychaos)) 
(send talk-s :start-server “path’) 
(do” ((control-s (send talk-s :check-sym 1) 
(send talk-s ‘check-sym 1) 
) 
) 
((setf time-to-quit “done*) 
(send talk-s :stop) 
) 


(cond 

((equal control-s “!*) 

(setf next-3 (send talk-s :check-sym 3)) 

(cond 
((equal next-3 “III") 
(setf map-str-utm-e (send talk-s :check-sym 5)) 
(setf map-str-utm-n (send talk-s :check-sym 5)) 
(setf veh-id (send talk-s :check-sym 10)) 


(setf next-3 (send talk-s :check-sym 3)) 
(cond 


((equal next-3 “H!") 
(terpri) 
(princ “loading map") 
(sett map-utm-e (convert-string-to-integer map-str-utm-e)) 
(setf map-utm-n (Convert-string-to-integer map-str-utm-n)) 
(setf veh-map (inter (string-append 

(string-append “MAP” 

map-str-utm-e 
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) 
map-str-utm-n 
) 
) 
) 
(setf current-veh (intern (stnng-append “VEH" veh-id))) 
(do ((maps *maps’® (cdr maps))) 
((or (equal veh-map (car maps)) 
(null (cdr maps)) 
) 
(cond 
((equal veh-map (car maps)) 
(send talk-s ‘put-ready 
(stnng-append "READY" 
veh-id 
) 


) 
((null (cdr maps)) 


(setf (symbol-value veh-map) (make-array ‘(102 102))) 
(setf °“maps* (cons veh-map *maps")) 
(send talk-s ‘put-ready 
(string-append (load-map 100 
map-utm-e 
map-utm-n 
“bin-slope.dat” 
(symbol-value veh-map) 


) 
veh-id 


(setf (symbol-value current-veh) veh-map) 
(do ((vehs *vehs* (cdr vehs))) 
((or 
(eq current-veh (car vehs)) 
(null (cdr vehs)) 
) 
(cond 
((nutl (cdr vehs))) 
(setf *vehs* (cons current-veh *vehs*)) 
) 
) 
) 


Si) 


(terpri) 
(princ “map loaded’) 


((equal control-s "@") 
(setf next-3 (send talk-s :check-sym 3)) 
(cond 
((equal next-3 "@@@") 
(setf map-utm-e (send talk-s :check-sym 5)) 
(setf map-utm-n (send talk-s :check-sym 5)) 
(setf start-utm-e (send talk-s :check-sym 5)) 
(setf start-utm-n (send talk-s :check-sym 5)) 
(setf goal-utm-m-e (send talk-s :check-sym 5)) 
(setf goal-utm-m-n (send talk-s :check-sym 5)) 
(setf veh-id-str (send talk-s :check-sym 10)) 
(setf next-3 (send talk-s :check-sym 3)) 
(cond 
((equal next-3 "@@@") 
(setf map-utm-e (convert-stnng-to-integer map-utm-e)) 
(setf map-utm-n (convert-stnng-to-integer map-utm-n)) 
(setf start-utm-e (convert-string-to-integer start-utm-e)) 
(setf start-utm-n (convert-string-to-integer start-utm-n)) 
(setf goal-utm-m-e (convert-string-to-integer goal-utm-m-e)) 
(setf goal-utm-m-n (convert-string-to-integer goal-utm-m-n)) 
(setf veh-id (convert-string-to-integer veh-id-str)) 
(setf start-utm-e (floor (/ (- start-utm-e map-utm-e) 100))) 
(setf start-utm-n (floor (/ (- start-utm-n map-utm-n) 100))) 
(setf goal-utm-e (floor (/ (- goal-utm-m-e map-utm-e) 100))) 
(setf goal-utm-n (floor (/ (- goal-utm-m-n map-utm-n) 100))) 
(setf current-veh (intern (string-append "VEH" veh-id-str))) 
(terpri) 
(princ “planning path”) 
(terpri) 
(prince start-utm-e) 
(terpri) 
(pnnc start-utm-n) 
(terpri) 
(pnnc goal-utm-e) 
(terpri) 
(princ goal-utm-n) 
(setf “wave-paths’ (cons 
(add-seq-num 
(add-id 
(convert-to-utm 
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(append 
(wave Start-utm-e 
Start-utm-n 
goal-utm-e 
goal-utm-n 
(symbol-value 
(symbol-vale current-veh) 
) 
) 
(list (list goal-utm-e goal-utm-n)) 
) 
map-utm-e 
map-utm-n 
) 
veh-id 
) 
) 


*wave-paths’ 


) 


(cond 
((not (atom “*wave-paths’)) 
(setf °wave-paths’ (send-waypoints *wave-paths’)) 
) 
) 
) 
) 


(defun new-utm (num map-org) 
(+ Map-org (* num 100) (random 100)) 


) 


oy) 


:3, -*- Package: USER; Mode: LISP; Syntax: Common-lisp -*- 
; Tide: Ir-wave.lisp 

‘Author: Shannon 

;Date: 20 May 1989 

-Discription: This program is the implimentation of a wavefront search algorithm. 
; (wave number-of-explored-cells touched-flag) 

(defvar *cost-array”*) 

(defvar *center-cell*) 

(defvar *s-wave") 

(defvar “g-wave*) 

(defvar *array-size") 

(defvar *map-loaded") 

(defvar *map-array*) 

(defvar “start-loc*) 

(defvar *goal-loc*) 

(defvar *parent-array*) 


‘(sett “map-size*) 
(setf “start-loc* ‘(2 2)) 
(setf “goal-loc® ‘(10 10)) 


(defun parent-p(x y) 
(aref *parent-array” x y)) 


(defun set-new-cost(x y cost) 
(setf (aref *cost-array* x y) cost)) 


(defun set-new-parent(x y parent-x parent-y) 
(setf (aref “parent-array” x y) (list parent-x parent-y))) 


(defun retnieve-cost(x y) 
(aref “cost-array* x y)) 


(defun retrieve-parent(x y) 
(aref *“parent-array* x y)) 


(defun get-cost-from-map(x y) 
(aref “map-array* x y)) 


(defun load-map (mapsize map-e map-n mapfile veh-map) 
(setq input-stream (open mapfile ‘direction ‘input :byte-size 8 :characters nil)) 
(setf map-loc (+ (* (floor (/ (- map-e 41000) 1000)) 10) 
(* (floor (/ (- map-n 60000) 1000)) 3500))) 
(setf *“array-size* (+ mapsize 2)) 
(setf “map-array* veh-map) 
(do ((ycoord 0 (+ ycoord 1))) 
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((= ycoord “array-size")) 
(setf (aref “map-array” 0 ycoord) -2) 
(sett (aref “map-array” (- “array-size* 1) ycoord) -2)) 
(do ((xcoord 0 (+ xcoord 1))) 
((= xcoord *array-size*)) 
(sett (aref “map-array* xcoord 0) -2) 
(setf (aref *map-array® xcoord (- *array-size* 1)) -2) 
) 
(do ((ycoord 1 (+ ycoord 1))) 
((= ycoord (- *array-size” 1))) 
(file-position input-stream map-loc) 
(do ((xcoord 1 (+ xcoord 1))) 
((= xcoord (- *array-size” 1))) 
(setf slope (read-byte input-stream)) 
(setf slope (+ (/ (+ 0.0 slope) 2) 1)) 
(cond 
((> slope 15) (setf slope -2))) 
(setf (aref “map-array* xcoord ycoord) slope) 
) 
(setf map-loc (+ map-loc 350)) 
) 
(close input-stream) 
(setf “map-loaded” 'yes) 
“READY” 
) 


(defun wave(start-e start-n goal-e goal-n veh-map) 
(cond ((equal *map-loaded’ 'yes) 
(setf *start-loc’ (list start-e start-n)) 
(sett “goal-loc’ (list goal-e goal-n)) 
(setf *map-array* veh-map) 
(read-terrain-data) 

(initial-expand) 

(normal-expand) 

(report-solution) 

) 

(t 


'‘no-map-available))) 


(defun report-solution() 
(append (reverse (follow-link (first “center-cell*) (second *center-cell*))) 
(cdr (follow-link (first “center-cell*) (third *center-cell*))) 
) 
) 


(defun follow-link (pos1 pos2) 
(cond ((equal pos1 pos2) 
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(list pos2)) 
(t 
(cons posi 
(follow-link 
pos2 
(retneve-parent (first pos2) 
(second pos2))))))) 


(defun read-terrain-data() 
(let ((cost) (start-x) (start-y) 

(goal-x) (goal-y)) 
(setf *parent-array* (make-array (list “array-size* *array-size’))) 
(setf *cost-array” (make-array (list “array-size” *array-size"))) 
(copy-array-contents *map-array® “cost-array*) 
(setf start-x (first “start-loc*)) 
(setf start-y (second “start-loc’)) 
(setf goal-x (first *goal-loc’)) 
(setf goal-y (second *goal-loc’)) 
(set-new-parent Start-x start-y start-x start-y) 
(set-new-parent goal-x goal-y goal-x goal-y) 
(set-new-cost Start-x start-y -1) ; wave-name 
(set-new-cost goal-x goal-y 0) ; wave-name 
(pnnt ‘'done-terrain-classification) 


)) 


(defun inital-expand() 
(do () 
((setf *s-wave’ (init-expand -1 (list *start-loc’)))) 
) 
(do () 
((setf °g-wave”® (init-expand 0 (list °goal-loc*)))) 
) 
) 


(defun init-expand(wave-name wave) 
, retrun: a-wave 
(first (expand-8 (car wave) wave-name))) 


(defun expand-8 (pos wave-name) 
(let ((x (first pos)) 
(y (second pos))) 
(orthog-expand (- x 1) y x y wave-name 
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(orthog-expand (+ x 1) y x y wave-name 
(orthog-expand x (+ y 1) x y wave-name 
(orthog-expand x (- y 1) xy wave-name 
(diag-expand (- x 1) (+y 1) x y wave-name 
(diag-expand (+ x 1) (+ y 1) x y wave-name 
(diag-expand (+ x 1) (-y 1)x y wave-name 
(diag-expand (- x 1) (- y 1) x y wave-name 


(list nil © 0))))))))))) 


(defun normal-expand() 
(do () 
((or (expand-s-wave) 
(expand-g-wave)) 
(pnnt ‘wave-found)) 
) 
) 


(defun expand-s-wave() 


(set-new-s-wave (cycle-thru-wave “s-wave” -1 nil))) 


(defun expand-g-wave() 


(set-new-g-wave (cycle-thru-wave *g-wave* 0 nil))) 


(defun set-new-s-wave(new-wave-data) 
(setf *s-wave* (car new-wave-data)) 
(>= (second new-wave-data) 1)) 


(defun set-new-g-wave(new-wave-data) 
(setf “g-wave’ (car new-wave-data)) 
(>= (second new-wave-data) 1)) 


(defun cycle-thru-wave(wave wave-name t-wave) 
(cond ((null wave) 
(list t-wave 0 nil)) 
(t (let’ 
((pos (Car wave)) 
(x (first pos)) 
(y (second pos)) 
(a-parent (retneve-parent x y)) 
(dx (- x (first a-parent))) 
(dy (- y (second a-parent))) 
(wave-data (sub-expand dx dy x y wave-name t-wave)) 
(wave-data 1 
(cycle-thru-wave (cdr wave) wave-name 
(add-back-to-wave pos wave-data)))) 
(list (first wave-data 1) 
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(+ (second wave-data1) (second wave-data)) 


nil))))) 


(defun add-back-to-wave (pos wave-data) 
(if (>= (third wave-data) 3) 
(first wave-data) 
(cons pos (first wave-data)))) 


(defun sub-expand(dx dy x y wave-name wave) 
(cond ((equal dx 0) 

(sub-expand1 (+ y dy) x y wave-name wave)) 

((equal dy 0) 

(sub-expand2 (+ x dx) x y wave-name wave)) 

(t 


(sub-expand3 (+ x dx) (+ y dy) x y wave-name wave)))) 


(defun sub-expand1(ny x y wave-name wave) 
(diag-expand (+ x 1) ny x y wave-name 
(orthog-expand x ny x y wave-name 
(diag-expand (- x 1) ny x y wave-name (list wave 0 0))))) 


(defun sub-expand2(nx x y wave-name wave) 
(diag-e xpand nx (- y 1) x y wave-name 
(orthog-expand nx y x y wave-name 
(diag-expand nx (+ y 1) x y wave-name (list wave 0 0))))) 


(defun sub-expand3(nx ny x y wave-name wave) 
(orthog-expand nx y x y wave-name 
(diag-expand nx ny x y wave-name 
(orthog-expand x ny x y wave-name (list wave 0 0))))) 


(defun orthog-expand (x y px py wave-name wave-data) 
(a-expand x y px py 1.4142 wave-name wave-data)) 


(defun diag-expand (x y px py wave-name wave-data) 
(a-expand x y px py 1 wave-name wave-data)) 


(defun a-expand (x y px py amount wave-name wave-data) 

(if (not (parent-p x y)) 
(set-new-parent x y px py)) 

(let ((cost (retrieve-cost x y))) 

(cond 
((and (equal cost -1) 
(equal cost (other-wave-p wave-name))) 

(setf *center-cell* 
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(list (list x y) 
(retneve-parent x y) 
(list px py))) 
(list (first wave-data) 
(+ (second wave-data) 1) 
(+ (third wave-data) 1))) 
((and (equal cost 0) 
(equal cost (other-wave-p wave-name))) 
(setf *center-cell’ 
(list (list x y) 
(list px py) 
(retrnieve-parent x y))) 
(list (first wave-data) 
(+ (second wave-data) 1) 
(+ (third wave-data) 1))) 
((and (equal (retneve-parent x y) (list px py)) (> cost 0)) 
(a-expand1 x y px py (- cost amount) wave-name wave-data)) 
(t 
(list (first wave-data) 
(second wave-data) 
(+ (third wave-data) 1)))))) 


(defun a-expandi(x y px py new-cost wave-name wave-data) 
(cond ((> new-cost Q) 
(set-new-cost x y new-cost) 
wave-data) 
(t 
(my-overflow x y px py new-cost wave-name 
(a-expand2 x y wave-name wave-data))))) 


(defun a-expand2(x y wave-name wave-data) 
(set-new-cost x y wave-name) 
(list (cons (list x y) (first wave-data)) 
(second wave-data) 
(+ (third wave-data) 1))) 


(defun other-wave-p (wave-name) 
(if (equal wave-name 0) 
-1 
0)) 


(defun my-overflow (x y px py cost wave-name wave-data) 
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(cond ((< cost 0) 
(let® ((ax (+ x (- x px))) 
(ny (+ y (- y py))) 
(cost! (retrieve-cost nx ny)) 
(new-cost (+ cost cost1))) 
(if (not (parent-p nx ny)) 
(set-new-parent nx ny x y)) 
(cond ((and (equal (retrieve-parent nx ny) (list x y)) (> cost1 0)) 
(cond ((> new-cost 0) 
(set-new-cost nx ny new-cost) 
wave-data) 
(t 
(set-new-cost nx ny wave-name) 
(my-overflow 
nx ny x y new-cost wave-name 
(list (cons (list nx ay) (first wave-data)) 
(second wave-data) 
(third wave-data)))))) 
(t 
wave-data)) 
)) 
(t 
wave -data))) 
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APPENDIX C USER INTERFACE 


The user interface of any application program must be designed so that novice and 
experienced users alike can effectively operate the program with little or no help from 
user’s manuals or other users. This is achieved by a thorough and efficient design of 
command line options, popup menus, dials, and the use of the mouse. This appendix 
provides instructions on starting up and running APS, both the vehicle simulator and 
the path planner, and navigating through the menus and operating controls of the sys- 


tem. 


I. VEHICLE SIMULATOR" 
The section covers the user interface to the vehicle simulator by describing 


starting procedures, the menu system, and platform controls. 


A. COMMAND LINE OPTIONS? 
The vehicle simulator is started by typing "aps" followed by any command 
line options and pressing RETURN. There are currently three options available from 
the command line. 


¢ Network mode 
¢« Test mode 
e Silent mode 


Selection of the network mode activates the networking capabilities of the 
program. In this mode update messages are sent and received from any other vehicle 
simulators as well as the path planner. Vehicle simulators operating on different 


machines will be able to share information regarding the other platforms. When a 


The main modifications to the MPS user interface are in the driving controls, weapon system controls and additional menu options. 
The entire user interface is documented here for completeness. Where the MPS interface is unmodified, it is an extract of Appendix 
A of [FICHTN88]. 

2 


The code that processes the command line arguments is contained in the file decode_arguments.c. 
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platform fires, changes guidance mode, or changes course, speed or altitude (FOGM 
only), a message is sent to all other vehicle simulators and to the AI agent updating 
the local database for the appropriate platform. 
Selection of test mode bypasses some of the cosmetic portions of the pro- 
gram. Currently, the only part that is bypassed is the opening billboard sequence. 
Selection of silent mode turns off the bell that rings to indicate acceptance 
of input from the user. This option is useful for demonstrations when the ringing 


would interfere with a verbal explanation of the program. 


B. POPUP MENU SYSTEM? 

Popup menus are the primary source of user control over the state of the 
program. There are currently 24 different popup menus that are used in various parts 
of the simulation. If a selection in a menu is not allowed or meaningful when the menu 
is displayed, the selection is displayed in lower case. Otherwise the selection is com- 
pletely uppercase. Invalid selections are retained in the menu so that the menus al- 
ways appear in the same order and format every time. If disallowed selections were 
omitted completely, users would tend to be overwhelmed by the number of different 
menu formats. 

A menu is displayed and the selection always made by depressing the 
right mouse button. Roll-off menus are expanded by moving the cursor arrow to the 
right when a menu item with a roll-off submenu (such selections have a small arrow 
on the nght-hand side) is highlighted. The following is a detailed explanation of each 


menu. 


3the code for defining all static popup menus is contained in the file makepopups.c. Code for displaying and processing menu 
selections is contained in the following files: do_main.c, do_driving_menu.c, do_flying_menu.c, do_change_speed.c, do_intros.c, 
do_pathops.c, do_quitting.c, do_select_area.c, do_the_add.c, do_the_defaults.c, do _the_delete.c, do_the_select.c, and 
select_sightc. 
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I. Opening Menus 
There are two menus that make up the opening menu set. These 
menus are called OPENING _ONE and OPENING_TWO. Each of these menus con- 
tain the same four selections as follows: 


¢ DISPLAY INSTRUCTIONS 

¢ GOTO SELECT AREA MENU 

¢ EXIT THE PROGRAM 

¢ ENTER 4SIGHT (RESIZE OPTIONS) 


OPENING_ONE allows the user to select any one of these options 
but OPENING_TWO disallows the first option. OPENING_TWO is displayed if the 
user is currently looking at the instruction page. 

The first selection displays a page of instructions onthe user inter- 
face. If the instruction page is being displayed or the user wishes to bypass the in- 
struction page, the GO TO SELECT AREA MENU selection will do just that. To exit 
the program, the uSer must select EXIT THE PROGRAM and a small menu will be 
displayed with the following selections: 


¢ RETURN TO WHERE YOU WERE 
fee eALLY QUIT 


If the user desires to resize or move the simulation’s windows, the 
option ENTER 4SIGHT (RESIZE OPTIONS) will allow him to accomplish it. After 
selecting the option, the windows will be cleared to white and the user can click on 
the menu bar and move or resize as desired using normal window manager functions. 

2. Select Area Menu 

The select area menu is active whenever the 35 KM 2D map is dis- 

played. It contains the following options: 


¢ SELECT AN AREA OF THE MAP 
¢ GOTO MAIN MENU 
¢ EXIT THE PROGRAM 
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¢ ENTER 4SIGHT (RESIZE OPTIONS) 

¢ COLOR SCHEME - BROWN RAMP 

¢ COLOR SCHEME - MULTIPLE COLORS 
¢ COLOR SCHEME - GREY RAMP 

¢ COLOR SCHEME - RED RAMP 

¢ COLOR SCHEME - GREEN RAMP 

¢ COLOR SCHEME - BLUE RAMP 

¢ GOTO INTRODUCTION SCREEN 


Selecting GO TO MAIN MENU will take the user to the main menu 
which is the next logical place to go after selecting a 1OKM area in which to operate. 

The color scheme selections change the way the terrain is colored. 
Each color scheme has eight different colors that are based on the elevation at that lo- 
cation. The simulation actually uses 16 colors to create a checkerboarding effect, how- 
ever the user is only shown the eight primary colors in the color ramp. 

The last selection allows a user to return to the introduction screens 
if he desires. 

3. Main Menu 
The main menu contains the following ten selections: 


« ' PLACE DEFAULT SET OF PEATEORMS 
¢« ADD A PLATFORM 

¢ DELETE A PLATFORM 

¢ SAVE PLATFORMS TO A FILE 

¢ SELECT A PLATFORM TO OPERATE 

¢ ENTER 4SIGHT (RESIZE OPTIONS) 

¢ SELECT ANOTHER AREA OF THE MAP 
¢ PERFORM PATH OPERATIONS 

¢ OBSTACLES ON/OFF => 

¢ EXIT THE PROGRAM 
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Selecting the first option (PLACE DEFAULT SET OF PLAT- 
FORMS) will display another menu called DEFAULT_MENU. This menu contains 6 
selections as follows: 


e ENTER THE FILENAME FOR YOUR PLATFORMS 
¢ CONVOY - 10 GROUND PLATFORMS 

¢ CONVOY - 10 GROUND & 1 FOGM PLATFORM 

e JEEPS - 20 IN A ROW 

¢ DR. ZYDA’S CONVOY 

¢ DR. ZYDA’S WILDMAN DEFAULTS 


If the user selects the first option, a small window is displayed on the 
screen which prompts the user for the filename. If valid information is found in the file, 
the appropriate platforms are added to the simulation. The main menu is then redis- 
played. 

Selection of any other option on the DEFAULT_MENU results in the 
addition of predesignated platforms in predesignated locations. These selections are 
useful for demonstration purposes and for persons interested in getting some plat- 
forms on the screen very quickly. 

The information for the default sets of platforms is contained in data 
files that are read when indicated by a menu selection. The complete path for these 
files is contained in the header file “‘files.h”. 

The next option on the main menu is ADD A PLATFORM. Selecting 
this option displays the following menu: 


¢ ADD A COVERED JEEP 

¢ ADD AN OPEN JEEP 

¢ ADD A TRUCK 

¢ ADD A TANK 

¢ ADD A TOW VEHICLE 

¢ ADD A FOGM MISSILE 

¢ ADD AN ATTACK HELICOPTER 
¢ ADD AN OBSTACLE 
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If a moving platform is selected Geep, truck, tank, TOW, attack heli- 
copter, or FOGM), menus are displayed requesting an initial speed and direction for 
the platform. If an obstacle is requested, then the speed and direction menus are by- 
passed. The FOGM missile defaults to an initial altitude of 50 meters above the ter- 
rain at the point where it is placed. After completing the selections, an icon is placed 
in the center of the screen that resembles the selected platform or obstacle. The user 
can then move the icon with the mouse and place the platform by clicking the nght 
mouse button. After placing the icon on the screen, the main menu is displayed once 
again. 

Selecting the DELETE A PLATFORM option displays the following 
menu: 


¢ DELETE A SINGLE PLATFORM 
¢ DELETE ALL PLATFORMS ON THE SCREEN 


If the user wants to delete one platform, an X cursor is displayed and 
the user can click on the desired platform. If the user wants to delete all the platforms 
on the screen, the following menu 1s displayed: 


¢ NO, DO NOT DELETE ALL THE PLATFORMS 
¢ YES, DELETE ALL PLATFORMS 


The appropriate selection from this menu either cancels the operation 
or executes it. This menu prevents a user from deleting vehicles that he may not real- 
ly want to delete. 

If the user has placed platforms on the screen and wishes to save 
them to a file, then the main menu selection SAVE PLATFORMS TO A FILE accom- 
plishes this. A window opens that prompts the user for the filename. If the path is cor- 


rect, the platforms are saved to the file. 
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The next selection from the main menu is SELECT A PLATFORM 
TO OPERATE. If the user selects this option, the following menu is displayed: 


¢ ZOOM IN TO ANY LEGAL GRID SQUARE 
¢ SELECT A PLATFORM TO OPERATE RIGHT NOW 


The zoom option is usually necessary if platforms are close to each 
other and the individual icons overlap. By zooming into the 1x1 kilometer grid square, 
the user can more easily select the platform he desires. If the platform the user 
wants to operate is clearly visible, then the second selection allows the user to select 
a platform immediately. 

The SELECT ANOTHER AREA OF THE MAP option returns to 
the SELECT_AREA menu and redisplays the 35KM map. 

Selecting PERFORM PATH OPERATIONS from the main menu dis- 
plays a submenu containing up to four path manipulation functions. These functions 
are: 

¢ DISPLAY PATHS ON/OFF => 
me ONS TRUCT PATH 

meee LETTE PATH 

¢ ASSIGN VEHICLE TO PATH 


The last two options are not displayed if there are no paths to delete 
or no vehicles to assign to a path. The first selection is a toggle that turns the display 
of paths on the 1OKM map on and off. The other selections allow manipulation of 
paths. When a function is invoked by selecting it, specific instructions are displayed 
in the lower right menu window. 

4. Operating Menus 

Operating menus are available when a platform has been selected 

and is being driven by the user. They generally affect the characteristics of the 3D 


terrain display or how the vehicle is being controlled. 


ie: 


a. Driving Menu. This menu is called OPERATE_DRIVE. It 
contains ten selections: 


¢ DONOTHING 

¢ RETURN TO MAIN MENU 

¢ CHANGE ALL PLATFORMS’ SPEEDS 
¢ EXIT THE PROGRAM 

¢ ENTER 4SIGHT (RESIZE OPTIONS) 

¢ POP WINDOWS 

¢ CHANGE VIEW 

¢ ADVANCED OPTIONS => 

¢ AUTOPILOT ON/OFF => 

¢ GUIDANCE ON/OFF = 


The first selection is provided in case the user pushes the mght 
mouse button and he does not desire to do anything. The second selection returns the 
user to the main menu. 

The third selection causes another menu to pop up that allows the us- 
er to select a speed for all the platforms currently in the simulation. The allowable 
speeds are from zero to 65 miles per hour. There is also a selection that will do noth- 
ing and return directly to the simulation. Changing all the speeds is convenient when 
the user wants to have a convoy of platforms proceed at identical speeds. Also, by se- 
lecting zero miles per hour, all platforms are effectively frozen and their configuration 
can be studied by viewing them from a FOGM missile or other platform. 

The POP WINDOWS selection brings the four windows of the simu- 
lation into view if any of them are obscured from view by other processes that are run- 
ning on the machine. 

If the CHANGE VIEW option is selected, a submenu containing dif- 
ferent operating modes is presented. All platforms have at least three options: 


¢ NORMAL VIEW - Normal commander’s view, all dials including course and 
speed are active. 
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¢ DRIVER’S STATION - Activates mouse joystick (Figure C-1). for driving the 
platform. In this mode moving the mouse move the steering cursor which 
controls the steering and throttle. The corresponding course and speed di- 
als are deactivated. 


¢ BINOCULARS - Gives view through a pair of vanable power binoculars. 


An additional selection is presented for each weapon system type 
and munition combination carried by the platform, 1.e., for a TOW vehicle a TOW se- 
lection is displayed along with the normal three views. 

The ADVANCED OPTIONS selection brings up the following menu: 


¢ TOGGLE SINGLE/DOUBLE BUFFER MODE 
¢ TARGETING MODE TEST (ONCE) 
¢ TERRAIN DRAWING OPTIONS 


The first selection toggles the graphics hardware between single- 
buffer and doublebuffer modes. In doublebuffer mode, all drawing is done in a separate 
area of memory from the display memory. When the function swapbuffers() is called, 
the pointer to this area and the pointer to the display buffer are switched, thereby 
swapping the new picture for the old picture. This is how smooth motion 1s simulated. 
If a user is interested in what order the individual picture elements are drawn on the 
screen, then by selecting singlebuffer mode, he can see the pictures while they are be- 


ing drawn. 
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Figure C-1 Mouse Steering Cursor 


Ws 


Targeting mode test allows a user to see how the simulation deter- 
mines if a target is in the crosshairs of the FOGM missile during targeting. After se- 
lecting the option, the next time targeting is attempted, the view will be cleared to 
white and all visible platforms will be drawn without lighting, shading, or hidden sur- 
face removal. The resulting picture is displayed for three seconds and then normal op- 
eration commences. This option is reset each time it is used. 

The TERRAIN DRAWING OPTIONS option is a roll-off menu. 
When the user moves the cursor towards the nght side of the words TERRAIN 
DRAWING OPTIONS, the following menu 1s displayed: 


* DEPAILED TERRAIN 
© DISTANCE ATTENUATION - NORMAL 
¢ DISTANCE ATTENUATION - BOUNDARIES DISPLAYED 


The default terrain drawing option is DISTANCE ATTENUATION - 
NORMAL. This drawing option establishes three zones in front of the driven platform 
and reduces the number of polygons that are displayed in each zone. The zone closest 
to the viewer is displayed with 100x100 meter polygons, the greatest resolution avail- 
able. The next zone uses 200x200 meter polygons and the last zone uses 400x400 
meter polygons. The selection DISTANCE ATTENUATION - BOUNDARIES DIS- 
PLAYED draws the boundaries between zones in cyan so the user can see where 
they are. The selection for DETAILED TERRAIN draws 100x100 meter polygons 
throughout the three zones. Users notice a significant decrease in the frames per sec- 
ond rate when this option is selected. If singlebuffer mode is also enabled during de- 
tailed terrain drawing, the algorithm that is used to draw the terrain becomes more 
obvious. 

The GUIDANCE ON/OFF toggles the guidance mode of the current- 
ly selected platform. It invokes the actions described in paragraph C of chapter three. 
A indicator light in the upper right window is also toggled to reflect the current guid- 


ance mode. 
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The AUTOPILOT ON/OFF option works much the same. It toggles 
the platform’s autopilot and its indicator light on and off. 

b. Flying. There are three menus that make up the flying menu 
set. These menus are called OPERATE_FLY_ONE, OPERATE_FLY_TWO, and 
OPERATE_FLY _THREE. This menu contains the seven selections as follows: 


¢ DO NOTHING 

¢ DETACH/RESUME OPERATING 

¢ RETURN TO MAIN MENU 

¢ CHANGE ALL PLATFORMS’ SPEEDS 
¢ EXIT THE PROGRAM 

¢ ENTER 4SIGHT (RESIZE OPTIONS) 

¢ TOGGLE TARGET TRACKING 

¢ ADVANCED OPTIONS 


Many of these options are exact duplicates of the options on the driv- 
ing menu. However, the DETACH/RESUME OPERATING and TOGGLE TARGET 
TRACKING options are different. 

The DETACH/RESUME OPERATING option allows a user to de- 
tach the cursor from the simulation while flying. During flying, the cursor is restricted 
to the simulation window because the mouse controls where the nose camera of the 
FOGM missile is pointed. Using this option, the user can point the camera where he 
wants to look and then free the mouse. To return to the simulation, the user must se- 
lect the same option once again. 

If the user has a ground platform in the crosshairs of the FOGM mis- 
sile and he wants to target it, he must make the TOGGLE TARGET TRACKING se- 
lection from the menu. If a platform was in the crosshairs, then the missile will lock on 
and track the platform. If the user wants to release the missile from tracking mode 


then another selection will turn off target tracking. 
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C. DIALS* 

The dial box that is supplied by SGI has eight dials numbered from zero to 
seven. They are organized in two columns and four rows. The numbering scheme is 
from left to right, bottom to top so the lower left dial is zero, the lower right is one and 
the upper right 1s seven. 

The Autonomous Platform Simulator uses these dials in basically three 
configurations; one for driving a platform that has no weapon system, a second for 
driving a weapon equipped platform and a third for flying the FOGM. When the vehi- 
cle i being driven using the mouse joystick, the course and speed dials are inactive. 
When looking through the weapon sight of a platform dials one and three affect the az- 
imuth and elevation respectfully of the weapon system. When in normal view mode 
dials six and seven perform this function and the weapon is controlled independently 
of vehicle course or viewing angle. 

I. Driving Dial Configuration 

The dials for driving (Figure C-2) are configured as follows: 


¢ DIAL 0 - Course 

¢ DIAL 1 - Viewing direction or weapon azimuth if a sight is active 
¢ DIAL 2 - Speed 

¢ DIAL 3 - Viewing elevation or weapon elevation if a sight is active 
¢ DIAL 4 - Hour of the day 

¢ DIAL 5 - Month of the year 

¢ DIAL 6- Traverse weapon system when not looking through sight 
¢ DIAL 7 - Elevate weapon system when not looking through sight 


The course is the direction of travel of the platform which is displayed 
in degrees. The viewing direction is the direction the driver’s head is looking left to 
right in relation to the course. When the course is changed, the viewing angle changes 
accordingly. Speed is the speed of the platform in miles per hour. View elevation 


‘the code for mitializing the dials is contained in the following files: setcontrols.c and setcontrols_fogm.c. Code for handling input 


from the dials’ movements is contained in the following files: handlecontrols.c, handlecontrols_fogm.c, and handlecontrols_partial.c. 
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moves the driver’s view up and down. The hour of the day and month of the year de- 


termine the location, color, and intensity of the sun. Figure C-2 is a picture of the dial 


box with the dials labeled for driving. 


2. Flying Dial Configuration 
The dials for flying are configured as follows: 


DIAL Q - Course 

DIAL I - Altitude 

DIAL 2 - Speed 

DIAL 3 - Not Used 

DIAL 4 - Hour of the Day 
DIAL 5 - Month of the Year 
DIAL 6 - Not Used 

DIAL 7 - Not Used 


Many of the dials are identical to the driving dial configuration except for al- 


titude which is self-explanatory. Figure C-3 is a picture of the dial box with the dials 


labeled for flying. 


D. Mouse? 


The mouse has many uses throughout the simulation. Its use can be bro- 


ken down into basically six groups: 


5 


Popup menu activation and selection 
Operating area selection 

Platform icon placement and selection 
FOGM missile nose camera control 
Mouse joystick driving control 
Weapon rangefinder and firing controls 


Code for handling the operations of the selections is contained in the file select_area_menu.c. Code for handling platform icon 


placement is contained in the files do_the_add.c and addveh.c. Code for driving using the mouse as a joystick is contained in 
setup_for_dniving.c. Code for handling FOGM missile nose camera control is contained in the files handlecontrols_fogm.c and 
handlecontrols_partial.c. 
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When operating a platform using the dials or mouse joystick the left and 
middle mouse buttons control the magnification of the view by zooming OUT or IN re- 
spectively as shown in Figure C-4. When looking through the sight of a weapon sys- 
tem the left and middle mouse buttons function as a rangerfinder and tngger. This 
arrangement is shown in Figure C-5. 

The mouse is used throughout the simulation to activate popup menus and to se- 
lect options. One of these options is to select an area from the large database. A 
10x10 kilometer red square is displayed on the 35x35 kilometer database and the 
mouse is used to move the square to the desired location. Platforms are placed and 
selected on the screen with the mouse. 

The nose camera of the FOGM missile is controlled with the movement of the 


mouse. This gives the user very fine control over targeting and viewing direction. 


E. Keyboard® 
The keyboard is only used to accept filenames from the user. All other user 


input is through the popup menus, dials, or mouse. 


Peaie for handling filename input is contained in the files get_name.c and do_char.c. 





Figure C-4 Mouse Button Assignments - Normal View 





Figure C-5 Mouse Button Assignments - Weapon Sight 
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I. 


PATH PLANNER 


The path planner portion of APS is not a stand alone process, it requires the ve- 


hicle simulator to be running. This section covers how to run the path planner portion 


of the vehicle simulator by describing starting and stopping procedures. 


A. INITIAL REQUIREMENTS 


The path planner requires that seven files be loaded across two Symbolics 


workstations. The following files are required on SYM4, where ART resides. 


pp-control.art 
irisflavor3.lisp 
chaosflavor.lisp 
comm-functions.lisp 
clock-functions.lisp 
def-interface.lisp 


The above files do not have to be loaded to begin with, but must be available for file 


access. The following files are required on another Symbolics workstation. 


big-slope.bin 
search-control.lisp 
chaosflavor.lisp 
comm-functions. lisp 


Ir-wave.lisp 


B. START PROCEDURES 


The path planner requires several preconditions to run properly. Since the 


path planner is not a stand alone program, APS must be brought up first in network 


mode. The path planner may be started anytime after APS has passed the initial 


screen display. Starting the path planner is divided into two sections. These sections 


are Starting the path planner control program, and starting the search control program. 
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I. Starting the Path Planner Control Program 
On SYM4, enter ART by typing the SELECT: button, then typing A. 
Load pp-control.art in the ART shell. Reset ART by clicking the left mouse button on 
reset. Left mouse click on run. The program will query the user as to which Symbolics 
workstation the search algorithm is loaded. After ensuring that the search control pro- 
gram is started on the other Symbolics workstation, select the appropriate letter. The 
program will then query the user as to which IRIS graphics workstation the vehicle 
simulation is running on. After ensuring that the simulation is already running in the 
network mode, select the appropriate letter from the menu. The path planner is now 
running on its own and needs no further user interaction. 
2. Starting the Search Control Program 
The search control program is loaded onto any Symbolics worksta- 
tion, other than SYM4 where the path planner control program is loaded. To start the 
search program, load search-control.lisp. Then in the LISP listener enter (start- 
search-control). The program will respond by loading all of its communications and 
search files, then initiate a wait for communications from the path planner control pro- 


gram on SYM4. No further user interaction is required. 


C. STOPPING THE PATH PLANNER 
When the user is finished with the path planner, it is halted by using the 
META, CONTROL, and ABORT keys simultaneously. Next, on SYM4, the user en- 
ters the dynamic LISP listener and sets the user package to ACU (ART Common Us- 
er), and clears the communications paths by entering the following: 
¢ (scl:send talk-i :stop-iris) 
¢ (scl:send talk-s :stop) 
The search control program is halted in an identical manner as the path planner 


control program, but there is no need to enter a special LISP package to clear the com- 
munications path. The communications path for the search control program is cleared 


by entering (send talk-s :stop). 
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APPENDIX D KNOWN BUGS and SUGGESTED CODE IMPROVEMENTS 


1. The timer is currently reset when a vehicle is selected/reselected to operate 
from the main menu. This causes errors in timed events on the event list such as 
rounds in flight, safety reset, etc.. 

2. The Cobra attack helicopter is controlled the same as a ground vehicle. 

3. Guidance for LOS guided weapons, specifically the TOW, uses the current 
weapon azimuth and elevation, not the parameters at the moment of firing like a bal- 
listic round. This is correct but still fails to move the round onto the LOS at the 
crosshairs of the sight reticle. In check_round_in_flight(), the round should be moved 
to its new updated position by moving towards the current point of aim while being 
kept within the turning limits of the missile control system. 

4. A separate eye position should be added to provide additional viewpoints on 
each vehicle. Each vehicle should have a eye position for: normal view (TC), driver’s 


view, and weapon view. This should be accomplished by adding the following data 


Structure: 
#define TC POSITION 0 
#define DRIVER_POSITION 1 
#define WEAPON_POSITION 2 


float eye_position[vehtype][view_position][x,y,z] 


5. |The FOGM controls no longer work correctly. The pan direction is reversed 
and the course is fixed at 90 degrees. 

6. The network(SEND_END_ MESSAGE) function causes remote simulators to 
crash. Since net ids are now unique, the range of ids can no longer be calculated. 
Therefore, the terminating simulator must send a delete message for each of its local 
platforms when terminating. 

7. In some cases, the autopilot will cause a platform to endlessly orbit the 


goal. Normally a platform approaches a guide point head-on and stops or turns. If 
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the vehicle is outside the stopping distance and facing away from the goal when the 
autopilot is engaged, then the vehicle can get into a situation where it passes by the 
guide point before it completes its turn to head for it. This results in a circular path 
around the guide point. This should be taken care of when the autopilot is made more 
accurate to handle obstacle avoidance. 

8. The display limiting algorithm in drawterrain doesn’t work properly for the 
extremely narrow field-of-view used for the 13X TOW sight. At certain angles not 
enough terrain is drawn so some blue sky background shows through. 

9. Calculating surface normals for 100 squares across and up requires 101 ele- 
vation data points. The 101st elevation doesn’t exist, resulting in bad normals along 
the top row and right column. This was fixed temporarily by extending the 100th ele- 
vation out to also be the 101st elevation which creates a light band of terrain in these 
border areas. The algorithm should be changed to either get the 101st elevation or 
extrapolate it based on 99th and 100th elevations. 

10. All matching of platform ids is done by linear search through the platform 
list. This is not a problem with only a handful of vehicles, but would cause serious de- 
lays for a more realistic number of platforms. This should be replaced by a hash table 


using platform 1d. 
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